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

On Sun, Aug 23, 2026 at 04:45:48PM +0800, Kevin J. McCarthy wrote:
>On Sun, Aug 23, 2026 at 08:46:52AM +0200, Rene Kita wrote:
>>I can't remember I ever saw that message, but I don't quite get it:
>>Attachment #2 modified. Update encoding for /tmp/f? ([yes]/no):
>>
>>This is after an 'echo a >> /tmp/f'. Why "Update encoding"?
>
>Mutt scans the attachment to determine whether to use 7-bit, 8-bit, QP, 
>or Base64 encoding.  It wants to make sure the encoding is still 
>appropriate.  This can also manually be edited via ^E <edit-encoding> in 
>the compose menu.
>
>It also scans text types to determine the charset to be used.
>
but that's not what this is referring to.
it's asking whether to update the mime-encoded copy in the draft 
message. it's an overly technical formulation.

>>I wonder what behaviour people would expect these days, when attaching 
>>a file is it a link to the current version or a snapshot of the file when 
>>it was attached?
>
the current behavior is just fine. i regularly trigger it by modifying 
files after i already scheduled them for attaching. and while i usually 
want to update the attachment, this isn't always the case.

>By default it points directly at the attachment, but you can use 
><get-attachment> to copy it to tmpdir, to prevent updates from touching 
>mutt's version.
>
>>I'd guess it is the former. So I'd say that the reason
>>that no one reported an issue might that people don't expect it and
>>never notice. I don't look at the attachments in my +Sent.
>
>Yeah, they might not.  The receiver might notice if the encoding was 
>wrong for a text attachment that suddenly had 8-bit chars added.  I 
>agree though, this is hard to say.

there is some serious disconnect with reality in these paragraphs.