Opened 2 months ago

Closed 2 months ago

Last modified 2 months ago

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

foo.c (490 bytes ) - added by bhaible 2 months ago.
test case foo.c

Download all attachments as: .zip

Change History (8)

by bhaible, 2 months ago

Attachment: foo.c added

test case foo.c

comment:1 by bipolar, 2 months ago

Related: #15102, #17242

comment:2 by waddlesplash, 2 months ago

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

comment:3 by bhaible, 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 waddlesplash, 2 months ago

Resolution: no change required
Status: newclosed

comment:5 by korli, 2 months ago

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

in reply to:  2 comment:6 by thebuck, 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.)

Last edited 2 months ago by thebuck (previous) (diff)

comment:7 by bhaible, 2 months ago

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.

Note: See TracTickets for help on using tickets.