more on maildir modification times!

[Nicolas Sebrecht]

On Wed, Mar 25, 2015 at 03:01:05PM +0100, Abdó Roig-Maranges wrote:

> Hi,

Hi,

> Since recent Janna's maxage fixes (25513e90387f60), offlineimap changed
> behaviour regarding file modification times.
> 
> I skimmed through the commit, and it seems it is enough to store the internal
> date in the Maildir filename to make Janna's fix work, and not touch the unix
> modification time of the file.

I think you're right.

> Do you agree? Is there any reason to play games with modification times of the
> file and set them to the message internal time?
> 
> I'm concerned with this, for two reasons:
> 
> 1. We already use file modification times to quickly detect label changes on a
>    local GmailMaildir. If now we change meaning to the modification times, we
>    will be using them with two different meanings. Things will still work, but
>    it's kind of ugly.

My bad, I forgot about that. Well to make it clear, it's wrong to update
the modification times of the files for the purpose of fixing maxage.

In fact, I wonder if I should revert the whole patch (25513e90387f60).

It applies to the initial logic of maxage[1] but the min(UIDs) new logic
of the current WIP (PATCH v4) should make this fix unnecessary.

[1]. When maxage relies only on datetimes for both sides to decide what
     mails are to take into account for the sync.

> 2. I personally use the modification times to detect modified messages, and run
>    some scripts on them. Since Janna's changes, the modification time changed
>    meaning, and broke my setup.
> 
> If everyone involved agrees, I'd like to make unix modification times always
> mean local file modification times. I would not touch the internal date on the
> filenames, which is what fixes the maxage thing.

One thing you could do NOW for sure is to document how we use the
modification times on files and the time sequence in the filenames.

This should prevent from further mistakes and avoid you to worry too
much about things like that in the future. You might want to check the
comments in the code, what could be done in the API documentation and
most importantly introduce a new "_doc/ImplementationDesigns.md" page
for the website.

FMPOV, it would be _very valuable_ to introduce a documentation
dedicated on the logics we use. We could later add the whole UID sync
logic, threading design, etc, etc. Not going to say more about how much
I think we lack such documentation but the fresh new website should make
it very pleasant to do. ,-)

Glad you chacked the last release candidate. May I ping you so you can
test the revisited maxage logic once merged, before I tag it stable?

Thank you Abdó,

-- 
Nicolas Sebrecht