Re: strange message before sending mail

On 8/19/26 15:10, Reed Underwood wrote:
> 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.


Sorry, I think you were saying the discrepancy has found its way into 
ctime/mtime. If that's so, then I think your/Kevin's fix makes sense.