Closed silby closed 4 years ago
Actually I think it should keep the mtime of the source?
Pushed code now to try a simple rename first, please test.
Looks good to me, works for me, seems to interact as I was hoping with mbsync(1)
, and I agree that simply keeping the mtime of the source file is simpler and less surprising than whatever I was suggesting when I was delaying sleep to mess around with email. Thanks for taking the suggestion!
When I use
mrefile(1)
to move a message to a different folder in my mail structure, the resulting file has a fresh modification time. This mtime ends up getting used by isync'smbsync(1)
when sending the message back to my mail host with an IMAPAPPEND
with an explicit internal time. The result is a refiled message on the IMAP server with a fresh internal time, as opposed to the original time the message was received.mdeliver -M
extracts theDate:
from each message to use as the mtime of the resulting file.mutt(1)
appears to have similar behavior when copying messages. I proposemrefile(1)
should behave this way as well, or optionally behave this way, to accurately perform the "move messages between folders" task.(It's late and I am unable to think through whether this should really be the job of
mrefile(1)
or ifmbsync(1)
usingAPPEND
instead of somehow usingCOPY
is a bug.)