#19038 closed bug (no change required)
stat() call bumps a file's access time
Reported by: | bhaible | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | System/POSIX | Version: | R1/beta5 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
According to POSIX https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_12 , the access time of a file should be "the time of last data access". That is, reading the data should increment it, but a stat() call should not.
This does not work in Haiku hrev57823 (from 2024-07-15).
How to reproduce: Compile and run the attached file foo.c.
gcc -Wall foo.c ./a.out
Expected output: Three times the same line, such as
atime = 1725220981 atime = 1725220981 atime = 1725220981
Actual output: Three different lines, such as
atime = 1725220981 atime = 1725220982 atime = 1725220983
Attachments (1)
Change History (8)
by , 2 months ago
follow-up: 6 comment:2 by , 2 months ago
BFS doesn't store access time. The access time will generally be the current time.
comment:3 by , 2 months ago
So it is as if there was a daemon running (as root) that constantly reads from all files on all disks at the same time. This looks POSIX compliant to me.
Feel free to close this ticket and #15102. I'll have the access-time tests skipped on Haiku in Gnulib.
comment:4 by , 2 months ago
Resolution: | → no change required |
---|---|
Status: | new → closed |
comment:6 by , 2 months ago
The access time will generally be the current time.
That's jarring, albeit most correct, as bhaible illustrates.
Rather report the modification time instead?
That is the net effect of the noatime
mount flag on Linux.
(Files have their atime adjusted together with mtime, but not directories. atime < mtime is a reality here.)
test case foo.c