On Wed, Jun 03, 2026 at 10:51:45AM +0200, Vincent Lefevre wrote:
On 2026-06-03 10:38:41 +0200, Vincent Lefevre wrote:In check_attachments (compose.c), Mutt doesif (stat(actx->idx[i]->content->filename, &st) != 0) [stat error handling] if (actx->idx[i]->content->stamp < st.st_mtime) [case "Attachment #%d modified. Update encoding for %s?"] So here, actx->idx[i]->content->stamp was strictly less than the timestamp from the above stat. But how is actx->idx[i]->content->stamp set? And is it always set or could have it been let uninitialized? If it was set by void mutt_stamp_attachment(BODY *a) { a->stamp = time(NULL); }
In the past I did notice it used time instead of the stat mtime. I'm guessing it was trying to save on stat calls, but it may also be because
it was used in receive mode.I'd want to double check mutt_stamp_attachment() can't be used in receive-mode (where there aren't actual filenames), otherwise we could look into just saving the mtime instead.
(in sendlib.c), is it guaranteed that the filesystem uses the same clock as time()? This might not be the case because according to /usr/bin/stat, the filesystem here has a time resolution of less than 1 second while time() has a 1-second time resolution.
Better to let Greg KH or Alex chime in here. I was under the impression that modern Linux has resolved clock synchronization issues across cores.
There may be a very rare issue with the actual "write" not making it all the way to disk and setting mtime before mutt grabs time().
I remember fun issues with inotify (monitor.c) having bugs where the directory mtime at the nanosecond level didn't actually guarantee a directory didn't change again (550771fd)...
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
