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. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
