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

On Fri, Aug 21, 2026 at 12:13:08PM +0800, Kevin J. McCarthy wrote:
>Recent Linux kernels have different clocks used for the time() system
>call and stat() st_mtime of a file.

actually, no clock is used for stat() at all.

>time() is set to use a lower granularity clock.

this sounds like something (mutt or at least some system config) is 
actually setting it.

also, i'd generally speak of precision rather than granularity. to me, 
the former seems more suggestive of general fuzziness, which seems more 
fitting here.

>This means that

we're still in non-sequitur land here.

>right around the change of
>seconds, there can be an "X" millisecond gap where time() seconds is
>behind st_mtime seconds.

so my proposal would be to replace the paragraph with:

"
Modern operating systems offer multiple clocks of different precision.  
Due to an implementation detail of the Linux kernel, there is a window 
of a few milliseconds where the coarse clock's seconds may lag behind 
the precise one's right after each change of seconds.

Recent Linux kernels use a precise clock for time-stamping files, while 
the time() function we use as a reference has been using a coarse clock 
for some time now.
"

(i made it as definite as possible, but please fact-check the 
assertions.)

>The change has led to a bug in Mutt, where recording the stamp of an
>attachment using time() sometimes has a "second" value earlier than
>the stat() st_mtime of the file just modified (again, due to the
>granularity difference of the clock used).
>
>This caused a sporadic false warning before sending an email, that the
>attachment has changed on disk since it was last checked.  For more
>details, see:
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1144613
>
>The attachment->stamp is only used to compare against the stat
>st_mtime of the file just before sending.  So it actually makes more
>sense to just record the previous st_mtime of the file.  This occurs
>during message composition, so an extra stat on a file that was just
>read is not likely to cause a meaningful slow down.
>
>Change mutt_stamp_attachment() to use st_mtime for the stamp.

>Since
>the function previously had no error case, use "time(NULL) + 1" as a
>fallback behavior in case stat fails or (for some strange reason) it's
>called for a receive-mode attachment.
>
this seems a bit sloppy at first sight, but i guess it's fine, as a 
legitimate error (e.g., attachment disappearing or fs becoming 
inaccessible) will be handled properly at a later point.
i'd still add a comment in the code to justify the fallback.

>Thanks to Vincent Lefèvre for reporting the issue and working on
>finding out the source of the bug.  Thanks also to the other
>contributors in the thread who helped with reproducing and diagnosing
>the problem: Ian Collier, Reed Underwood, and Steffen Nurpmeso.
>---
>
>I've tried to make the commit message clearer.  Please let me know if
>the explanation makes sense and my terminology is correct.  If not,
>please do make suggestions.  Thank you.
>
> sendlib.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
>diff --git a/sendlib.c b/sendlib.c
>index 150bc72d..0e4a8146 100644
>--- a/sendlib.c
>+++ b/sendlib.c
>@@ -1284,7 +1284,21 @@ static void mutt_set_encoding(BODY *b, CONTENT *info)
> 
> void mutt_stamp_attachment(BODY *a)
> {
>-  a->stamp = time(NULL);
>+  struct stat sb;
>+
>+  if (a->filename && stat(a->filename, &sb) == 0)
>+    a->stamp = sb.st_mtime;
>+  else
>+  {
>+    /* Recent Linux kernels have an issue where time()'s clock has a
>+     * lower granularity

"precision"

> than the stat st_mtime clock.  This can
>+     * result in time()'s second value being earlier than the st_mtime
>+     * seconds of a file just modified.  See:
>+     * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1144613.

> As
>+     * an error fallback case,
>
this qualification seems misplaced here; see above instead.

>add 1 to work around the behavior.
>+     */
>+    a->stamp = time(NULL) + 1;
>+  }
> }
> 
> /* Get a body's character set */
>-- 
>2.55.0
>