Re: strange message before sending mail

On 8/19/26 14:36, Vincent Lefevre wrote:
> On 2026-08-19 15:51:42 +0100, Ian Collier via Mutt-dev wrote:
>> This seems to mean that the Linux kernel has changed something about
>> how the time is obtained when touching a file;
> In my Debian bug report against the Linux kernel, Salvatore Bonaccorso
> thinks that this is due to
>
>    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4e40eff0b5737c
>    "fs: add infrastructure for multigrain timestamps".
>
> and suggested to use clock_gettime(2) instead of time(2).
>
>> but ultimately it is the time(2) call that is to blame.
> Yes, this is what I observed with
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <time.h>
>
> int main(void)
> {
>    while (1)
>      {
>        struct timespec ts;
>        time_t t;
>
>        clock_gettime(CLOCK_REALTIME, &ts);
>        t = time(NULL);
>        if (ts.tv_nsec < 0)
>          exit(1);
>        if (t < ts.tv_sec)
>          printf("%ld %ld\n", (long) t, (long) ts.tv_sec);
>      }
> }
>
> On 2026-08-19 13:59:45 -0400, Reed Underwood wrote:
>> Yes, you're correct. In glibc 2.44, time() uses a macro which is
>> defined as CLOCK_REALTIME_COARSE.
> However, is it guaranteed to be less or equal to the time given
> by CLOCK_REALTIME? This is not documented. If there isn't such
> a guarantee, this will not solve the problem for Mutt, because
> by using clock_gettime(CLOCK_REALTIME,...) instead of time(),
> the result could be reversed with "old" kernels, for which
> timestamps are less accurate.
>
> So I would say that the fix for Mutt would be
>
>   void mutt_stamp_attachment(BODY *a)
>   {
> -  a->stamp = time(NULL);
> +  a->stamp = time(NULL) + 1;
>   }
>
> as suggested by Kevin.
>
I think because time(), when using CLOCK_REALTIME_COARSE, has a 
resolution of 1ms, that means that the seconds value in the result for 
time() doesn't roll over until at least N.00100... So I think you have a 
smooth millisecond, minimum, during which you can have this 
counterintuitive result.

Is there a reason not to use the seconds member of the result from 
gettimeofday? If so, then, yes, the fix above seems fine (assuming 
there's no reason to believe the one second offset is a problem otherwise).

I missed a lot of the earlier discussion, so ignore me if I'm way off base.