On 2026-06-03 17:38:11 +0800, Kevin J. McCarthy wrote: > 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 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)...
Something else... I don't remember what I did here. Usually, I save the file with C-x C-s, then quit Emacs with C-x C-c. So there's about a 1-second delay, which should be enough to avoid issues if there is a tiny difference between different clocks or caches. But it is not impossible that I did C-x C-c without saving first, so that Emacs asks me whether I want to save the file, and in such an uncommon case, the file save and the time() call from Mutt would occur at almost the same time. Otherwise, since Mutt doesn't do a stat() in mutt_stamp_attachment(), I'm wondering whether this could be an issue like https://lists.openwall.net/linux-ext4/2022/05/11/15 which I had 4 years ago on another machine: a file was actually created about 30 seconds after the openat()+O_CREAT system call! -- 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)
