<DKIM> [PATCH 1/2] decouple utime_from_header from rtime
abdo.roig at gmail.com
Mon Apr 6 15:51:32 BST 2015
This one is ready to be applied, if you accept that we make utime_from_headers
nonfunctional on IMAP folders.
Also, you suggested adding a comment regarding direct feeding to dovecot. But I
think it is not necessary. We concluded that this patch doesn't break dovecot
anymore than it was broken before, isn't it?
Nicolas Sebrecht writes:
> 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.
>> 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
> 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.
More information about the OfflineIMAP-project