<DKIM> [PATCH] make savemessagelabels honor utime_from_header

[Nicolas Sebrecht]

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.

Right.

> 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.

utime_from_header meant:

 "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
  features.

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
that:
- 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
with utime_from_header.

Thoughts?

-- 
Nicolas Sebrecht