On 2026-08-19 13:41:08 +0800, Kevin J. McCarthy wrote: > On Wed, Aug 19, 2026 at 11:24:50AM +0800, Kevin J. McCarthy wrote: > > On Mon, Aug 17, 2026 at 07:38:22PM +0200, Vincent Lefevre wrote: > > > This has just occurred again (this time in the train). > > > > > > In case this matters: > > > > > > qaa:~[77%]> /usr/bin/stat /var/tmp/mutt-qaa-1000-2859-6061931621091561353 > > > File: /var/tmp/mutt-qaa-1000-2859-6061931621091561353 > > > Size: 2241 Blocks: 8 IO Block: 4096 regular file > > > Device: 254,1 Inode: 13252685 Links: 1 > > > Access: (0600/-rw-------) Uid: ( 1000/ vinc17) Gid: ( 1000/ vinc17) > > > Access: 2026-08-17 19:30:55.000617603 +0200 > > > Modify: 2026-08-17 19:30:55.000607627 +0200 > > > Change: 2026-08-17 19:30:55.000607627 +0200 > > > Birth: 2026-08-17 19:30:55.000440459 +0200 > > > > > > I can notice 2 things: > > > > > > 1. The times are just after 19:30:55. > > > > > > 2. The Modify and Change times are not equal to the Birth time, > > > which seems unusual > > > > Mutt creates the file and then invokes the editor. So the birth time > > should be when mutt creates it. But I'm skeptical about the minuscule > > gap between birth and modify unless you are somehow scripting the test.
This may not matter. The issue could be more likely (1). In any case "So the birth time should be when mutt creates it." is wrong, because after I quit the editor, Mutt creates a *new* file, perhaps only when $edit_headers is set. So it will happen a tiny fraction of second between this file creation and the call to time(NULL). For instance, I had -rw------- 1 vinc17 vinc17 415 2026-08-19 13:08:31 /var/tmp/mutt-qaa-1000-2859-527543913898417581 just after saing the file in Emacs. And after I quit Emacs, this became -rw------- 1 vinc17 vinc17 227 2026-08-19 13:08:48 /var/tmp/mutt-qaa-1000-2859-9657418356702544922 without the headers (hence the smaller size). > Oh, yes, I forgot about emacs backup-by-copying. That defaults nil (I have > mine set to t for a long time). If you have the as the default perhaps it's > emacs that is recreating the file. Maybe it does so in two steps, leaving > to the tiny difference in birth and modify time? I have (setq backup-by-copying t) ; in particular, to avoid bug 71074 as a workaround for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71074 but I suppose that this doesn't matter anyway (see above). -- 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)
