<DKIM> [PATCH 1/2] decouple utime_from_header from rtime

[Nicolas Sebrecht]

On Fri, Apr 03, 2015 at 03:17:35AM +0200, Abdó Roig-Maranges wrote:
> 
> Oh, you mean that utime_from_header should also affect IMAP folders?

That's how utime_from_message worked since introduced, AFAICT.

>                                                                      I imagined
> that this feature was intended for Maildirs. If someone has a use case for this
> we can do the same on IMAP folders, it's just a few lines of code.

That's exactly what I was trying to say. Just a side note.

> > When rtime was introduced, it really was to fix the modification file
> > times. The filename was not affected. This allowed John to feed Dovecot
> > directly with the OfflineIMAP Maildir, behind Dovecot's back. Let's call
> > this configuration "direct feeding".
> >
> > This was at the time IMAP/IMAP didn't exist, yet. Today, I think direct
> > feeding configurations are just wrong and users should migrate from
> > their direct feeding to IMAP/IMAP, instead. I expect there's a lot of
> > direct feeding configurations out there because this is how it was
> > implemented for a long time and probably what users were told to do.
> >
> > Since recent 25513e90387f6, Janna and me decided to put rtime
> > (INTERNALDATE) in the filename rather than use the modification file
> > time. But this was while fixing maxage in mind, only.

I'm wrong, here. We decided to put the remote INTERNALDATE in the
filename rather than the downloaded date and time...

> >                                                       By doing so, we
> > ARE breaking all existing direct feeding configurations.

... By doing so, I don't know how it will impact direct feeding.

> > IOW, the quick sync mode is used with WRONG assumptions of what the
> > modification file time really means FOR YEARS. This was mainly not
> > hurting because INTERNALDATE are always expected older than the download
> > date times of a sync.

I'm wrong here, too.

> > What you are doing with this last hunk is not only decouple
> > utime_from_header from rtime but also FIX the modification file times to
> > reflect only what it should be: last modification time of the file, as
> > expected for quick syncs.
> 
> Ok, I am a bit confused now. Let me ask some questions:

Let's forget. I did confused you because I've mixed things between the
different WIPs, bugs, real values of rtime plus other discussed issues.
I'm sorry about that.

> 1. Does anyone rely on the timestamp in the filename being the same as the
>    modification time? Or can we use different values in the filename and the
>    modification time?

Both should be unrelated outside of utime_from_header.

> 2. Is there people out there relying on doing funny things with modification
>    times? You mentioned the "direct feeding", but I don't understand what they
>    need and how we break it.

Each time we change the Maildir format, we expose users to new failures.

This is because we are not alone to work on the Maildir. It is a
database shared accross various softwares, each coming with its own assumptions.

> If the answer to question 2 above is yes, then the assumptions of those people
> were not met, because due to bugs, we were not interfering with the usual file
> mtimes anyways. Is this what you were saying? Then keeping not interfering with
> mtimes should not be any worse for them than it has been.

Correct.

> I'd argue that not messing with file modification times should be what we do by
> default, because I think it is what most people would expect. One thing we could
> do is add a config option "utime_from", with values:
> 
> - none:    leave modification times alone (default)
> - header:  use header date as modification time
> - remote:  use rtime (remote time) as modification date
> 
> Would this make sense?

Forget about the third. I'm mixing things because I believe we don't
honor Dovecot assumptions and I suspect this is because of this third
case. But as I said, direct feeding is a wrong setup we don't want to
support anymore.

> I can't write about this because I don't fully understand the direct feeding
> thing.

This is just this:

  IMAP server -> OfflineIMAP -> Maildir -> Dovecot (or whatever)

This is wrong and should be:

  IMAP server -> OfflineIMAP -> IMAP -> Dovecot (or whatever) -> Maildir


Otherwise, thinking twice, the patch looks good.

-- 
Nicolas Sebrecht