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.
It doesn't make sense to me, but maybe mutt gets control back and records the stamp as 19:30:54, while the file system syncs out the modification time (and birth?) later.
In any case, this may be a new behavior because of the switch to $tmpdraftdir, which as opposed to /tmp which may be in RAM in Debian.
Maybe we could bump the stamp up by one second without causing any real problems. What happens if you apply this to sendlib.c:
void mutt_stamp_attachment(BODY *a)
{
- a->stamp = time(NULL);
+ a->stamp = time(NULL) + 1;
}
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
