maxage causes loss of local email

[Nicolas Sebrecht]

On Sat, Mar 21, 2015 at 06:12:50PM -0400, Janna Martl wrote:

> So I did something really stupid in my (supposedly) "trivial things"
> patch: in __syncmessagesto_copy(), instead of
> 	copylist.remove(uid)
> it should be
> 	continue
> (line 773?).

A bit hard to follow from start to end. Could you please talk with
patches?

>              I realize this is already applied but could you just amend
> it? Sorry!

I'm the first troublemaker if I applied a patch that is wrong. It's not
much offensive, though:
- it's in 'next' after -rc3 release;
- we are still in candidates cycles;
- it's pubic since very few time.

Intead of amending it and apply a very similar patch, let's fix the fix
on top of the current tip. I guess it makes more sense while reviewing
what was done (for any git history reviewer).

> So that takes care of the maxage --> maxage + 1 "issue". However, I do
> claim that my point still holds, with a different edge case: the user
> copies (e.g. manually, with mutt's "save to mailbox" feature, etc.) an
> old message on the server to their local folder. It's "new", so it
> gets copied to the remote, whereupon it gets assigned a new UID.
> localfolder's change_message_uid() then updates the UID and changes
> the filename.

It's actually the behaviour since the beginning of OfflineIMAP. Whatever
coming in (copied/paste/etc) from outside of OfflineIMAP is considered
new and synced back again.

> (Aside: I think you're assuming that min_uid is calculated using
> remote; actually, I did it using the local folder, so local is done
> first, and then remote is the one that's entirely synced using uid's.
> Switching them won't fix the issue I'm talking about.)

You're prefectly right. I've read that in your patches and I'm still
mixing the order of computation. Sorry about that.

> Now sync again: the message was recently assigned a UID, but has an
> old date.

So, you're talking about the IMAP server.

>           (Note: in this case, internaldate = filename date, and
> that's actually bad.) 

There is not real concept of INTERNALDATE locally, neither from Maildir
format nor from the format of the filenames we use.

Pretending INTERNALDATE == filename does not make sense.

This is where you left me behind. :-)

>                       So it's not in the local messagelist
> (the one that's calculated first) because it's not within maxage, but
> it *is* in the remote messagelist, because its UID is higher than
> whatever cutoff we're using. So it gets deleted remotely.

Let's put the UID restriction process outside of the scan method, then.

I think you're currently more screwed by the lack of proper OOP in the
code than the algorithm logic which is good. ,-)

Since local is the first being involved:

- scan for all previously-synced filenames (UID is known) within maxage
  *and* filenames with unknown valid UID/datetimes.

- caller extract min_uid from localmessagelist,
  request the remote for min_uid:*,
  sync

  - if no min_uid found,
    the list is empty of known UID,
    apply maxage against remote,
    request remote for mails within (maxage + 1),
    sync

-- 
Nicolas Sebrecht