#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 , 3 weeks ago
follow-up: 6 comment:2 by , 3 weeks ago
BFS doesn't store access time. The access time will generally be the current time.
comment:3 by , 3 weeks 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 , 3 weeks ago
Resolution: | → no change required |
---|---|
Status: | new → closed |
comment:6 by , 3 weeks 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