<DKIM> [PATCH 2/2] remove some rtime nonsense

[Nicolas Sebrecht]

On Fri, Apr 03, 2015 at 02:33:48AM +0200, Abdó Roig-Maranges wrote:
> 
> > I guess this is wrong in the sense that rtime COULD have a value with
> > the utime_from_header thing, at least.
> 
> No no, it is really dead code. This patch does not change behaviour.
> 
> This belongs to the function savemessagelabels, there is no rtime passed in the
> arguments. We set rtime in this line
> 
> rtime = self.messagelist[uid].get('rtime', None)
> 
> but self.messagelist[uid] has no 'rtime' key. It has 'mtime' for the speeding up
> of label change detection, but no 'rtime', so the variable rtime is always None.

Oh! I always thought this [cache]messagelist format was well defined and
identical accross repository types (outside of the labels thing)...

FUCK.

I blam the lack of proper OOP for making code so HARD to overview and
understand. I want a messagelist class...

> On the other hand, GmailMaildir does honor utime_from_header in savemessage,
> because it just calls the parent savemessage.

But the parent MaildirFolder().savemessage() do honor utime_from_header.


> There is an other issue I just realized, which maybe is related to what you had
> in mind. Even if utime_from_header=true, syncing a label change updates the file
> modification time. So utime_from_header in a GmailMaildir does not guarantee
> that the file mtime coincides with the date in the header. It has never
> guaranteed that, and this is a bug.
> 
> I think that we can honor utime_from_header in GmailMaildir without interfering
> with the labels stuff, by just restoring the modification time to the one before
> changing labels, only when utime_from_header=true. A patch doing this
> follows in an other mail.
> 
> If you agree with this, disregard this patch and use the new one, please.

Ok.

-- 
Nicolas Sebrecht