stat() call bumps a file's access time

[bhaible]

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

[bhaible]

test case foo.c

[bipolar]

Related: #15102, #17242

[waddlesplash]

BFS doesn't store access time. The access time will generally be the current time.

[bhaible]

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.

[korli]

Or you might test on ext4, if it's supposed to work there.

[thebuck]

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.)

[bhaible]

Rather report the modification time instead?

This would not be ​POSIX compliant. Whereas the current behaviour (setting the atime to the current time) is POSIX compliant. See comment:3 above.