maxage causes loss of local email
nicolas.s-dev at laposte.net
Sat Mar 21 23:55:57 GMT 2015
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
> it should be
> (line 773?).
A bit hard to follow from start to end. Could you please talk with
> 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:*,
- if no min_uid found,
the list is empty of known UID,
apply maxage against remote,
request remote for mails within (maxage + 1),
More information about the OfflineIMAP-project