Re: [PATCH] Change attachment stamping to use stat st_mtime by default.

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)