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

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.
>