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

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