maxage causes loss of local email

[Janna Martl]

On Sat, Mar 21, 2015 at 09:14:05PM +0100, Nicolas Sebrecht wrote:
> Unless I'm mistaken, "messages newer than maxage" are not due to maxage
> being increased but because the date put into the local filename might
> not match the remote INTERNALDATE of the message. IOW, we have
> 
>  (remote) UID X -> INTERNALDATE D1
>  (local ) UID X -> filename date D2
> 
> The mistake is that we cannot guarantee that the local date D2 match D1.

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?). I realize this is already applied but could you just amend
it? Sorry!

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.

(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.)

Now sync again: the message was recently assigned a UID, but has an
old date. (Note: in this case, internaldate = filename date, and
that's actually bad.) 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.

For the record, fix #2 (making filename = current time for messages
whose UID just changed) does work; this essentially reverts the
effects of my first patch in this special case.


-- J.M.