<DKIM> [PATCH] make savemessagelabels honor utime_from_header
abdo.roig at gmail.com
Fri Apr 3 20:31:51 BST 2015
> Previously, if a mail got changed locally, I think utime_from_header was
> taking care of:
> 1. syncing the changes on remote;
> 2. fix the INTERNALDATE on remote;
> 3. fix the mtime on local files.
> utime_from_header meant:
> "make sure ALL local mtimes match internal date after EACH sync".
Are you sure about this? I think it has always meant
"set the mtime to whatever when first saving the message".
The call to os.utime was done from savemessage, and this is only reached when a
message is saved for the first time. On the next syncs, savemessage is never
called. And the rtime bits in savemessagelabels did nothing at all.
After all, maildir messages should never change locally, so there is no reason
for them to change modification times. flag changes or file moves will leave it
Then we abuse the maildir a little bit for the labels, and change messages
locally. The fact that the user will routinely change local file mtimes for the
labels, is what conflicts a little bit with utime_from_headers.
> "make sure local mtime match internal date ONCE a mail is first downloaded"
> "don't fix any further changes of mtime"
> So, we neither do (2) nor (3) anymore.
Agreed we loose 2. I think we never had 3.
> So that the assumption:
> "make sure ALL local mtimes match internal date after EACH sync"
> is verified. IOW, get (3) without relying on rtime (2).
This would make sense. My first though would be adding a new pass in BaseFolder,
just at the end, after syncing flags, that fixes the local mtimes when
However, I don't have much time, and since this is a feature I'm not interested
in, nor we break it anymore than it was broken by what I said above...
Do you maintain a TODO list for things to do when bored?
> If we do apply (3), quick sync mode is an offender to what we can expect
> with utime_from_header.
Well, it is a delicate thing. But we can do the the label quick sync detection
before "fixing mtimes", and it would still work, assuming manual label changes
update the mtime.
More information about the OfflineIMAP-project