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. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
