maxage causes loss of local email
nicolas.s-dev at laposte.net
Sun Mar 22 11:21:15 GMT 2015
On Sun, Mar 22, 2015 at 11:25:24AM +0100, Nicolas Sebrecht wrote:
> Good catch!
Now that we talked about the L back in time case, there is another
tricky case we won't fix it might worth to be aware of.
If message M is like L, UID unkown but newer time T, it might temporary
put put the scan into a bad state, returning a wrong list.
1. M is downloaded behind OfflineIMAP's back. UID unkown, time T within
maxage range. Sync, M get assigned a new UID = V on remote.
2. Second sync, M is rewritten with new UID V, time T.
3. Third sync at t3, if we are unlucky, M is taken as reference for
uid_min while the UID V is bigger than it should be regarding other
messages with time within maxage and UID < V.
4. Another sync at t4, M is no longer the UID cursor. Messages wrongly
excluded at t3 are now synced, back to normal. BUT messages wrongly
excluded at t3 AND not anymore within the current maxage range gets
So, the more there's time between t3 and t4, the more there are messages
that won't be synced while they should have be.
These are strong edge-cases because it becomes hurting only if:
- some messages must be copied out of OfflineIMAP;
- copied messages are taken as reference;
- there was a long time between t3 and t4.
That being said, we should document how it's bad to copy messages out of
OfflineIMAP with maxage enabled.
More information about the OfflineIMAP-project