<DKIM> [PATCH] make savemessagelabels honor utime_from_header
nicolas.s-dev at laposte.net
Fri Apr 3 12:17:01 BST 2015
On Fri, Apr 03, 2015 at 12:28:21PM +0200, Abdó Roig-Maranges wrote:
> Strictly speaking, it is not incompatible.
> This patch make sure we at least do not break the assumption of
> utime_from_header on a label change propagating from gmail to local. As far as I
> know, quick syncs is not affected by this!
> The only case in which quick sync makes use of the mtime is to detect when
> someone externally (via the mail client) changes a label. This will still change
> the mtime, and quick sync will still work.
> But then, it doesn't make much sense to use utime_from_header with labels,
> because to make label syncs from local to gmail, you will have to manually break
> the assumption of utime_from_header to change the label. But the software is not
> strictly broken.
I think I'm beginning to get why utime_from_header was almost
superseding rtime. I might be wrong but here is what I understand.
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.
"make sure ALL local mtimes match internal date after EACH sync".
IOW, it was using the remote rtime thing (2) as a way to fix the local
mtimes on successive syncs (in order to get (3)) for any local changes.
Now, we are changing the behaviour to:
"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.
What sounds "bad" with the historical way of working is that:
- (2) is not necessary to get (3);
- it was hijacking the rtime thing without taking care of the other
So, installing utime_from_header deep in rtime logic was probably more
about having (3) the lazy way: by relying on (2).
What sounds "bad" with the new way of working of utime_from_header is
- we should still apply (3): fix local mtimes back again to internal
date if there's any local change after each sync.
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).
>From what you said above, I conclude it's not the case but this would
require more checks.
If we do apply (3), quick sync mode is an offender to what we can expect
More information about the OfflineIMAP-project