On 8/21/26 04:09, Vincent Lefevre wrote:
On 2026-08-20 22:42:06 -0400, Reed Underwood wrote:
Good to know. I see that gettimeofday() in glibc effectively wraps
clock_gettime() (using CLOCK_REALTIME). Is that not guaranteed to be the
same syscall as any that might be used for the filesystem?
This is not true for Linux kernels that predate the 4e40eff0b5737c
change (< 6.13).
If not, what other clock might be used?
Perhaps it was CLOCK_REALTIME_COARSE, as the number of seconds in
st_mtime (i.e. ignoring the fractional part) was always <= the one
returned by time(), so that the issue with Mutt never occurred.
I thought the case was that the file mtime was greater than the stamp
obtained using time() (in compose.c, line 510)?
It seems pretty inconvenient if filesystem timestamps aren't
somewhat guaranteed to be comparable to a known clock.
It is probably comparable to a known clock, but we do not know
which one.
BTW, in the case the file is stored on NFS (since this is chosen
by the user), the clock would be the one of a different machine
(the NFS server).
So it seems better and more logical for me to test whether st_mtime
(or st_mtim) has changed, which is what we really want to know
(actually, we want to know whether the file contents have changed).
I was just thinking that, if the current function uses time(), a call to
something like clock_gettime would alleviate the problem with the coarse
seconds from time(). But it sounds like you're saying it's just generally
more accurate to use stat() (which doesn't seem too onerous in this case).
I don't see any issue with a call to stat(): this is done after a mail
has been composed or a file has been attached, which is where the
whole time will be spent (and the context is normally interactive).
