Oof. Yes, then comparing timestamps seems altogether problematic. Thanks
for clarifying.
On 8/21/26 08:43, Vincent Lefevre wrote:
On 2026-08-21 07:48:01 -0400, Reed Underwood wrote:
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)?
Yes. With the older kernels, this never occurs because I suspect that
the filesystem and time() use the same clock (CLOCK_REALTIME_COARSE).
With the new kernels, the filesystem changed to a mix of coarse-grained
and fine-grained timestamps, whose number of seconds may be strictly
greater than the one returned by time(). Hence the issue.
For the current Linux kernels, clock_gettime(CLOCK_REALTIME,...)
could be OK, but there is no guarantee that it is for other systems
or future Linux kernels. For instance, a system could choose a
monotonic time for the filesystem, and depending how this is
implemented, comparing with clock_gettime(CLOCK_REALTIME,...)
could yield the same issue.
