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.
