[PATCH 2/4] Re: Handle when UID can't be found on saved messages

[Vladimir Marek]

> > Message was stored to dstfolder, but we can't find it's UID. This means we can't
> > link current message to the one created in IMAP. So we just delete local message
> > and on next run we'll sync it back. Also fixed imap.savemessage description.
> > 
> > This was broken by e20d8b967942934ddbf4659b5ec328a9a18da6bc.
> 
> Thanks. Whole topic looks interesting enough to have another -rc4 cycle
> before the stable, IMHO.

I'm sorry to break your cycle. I have to schedule real life too :)



> > +            elif newuid == 0:
> > +                # Message was stored to dstfolder, but we can't find it's UID
> > +                # This means we can't link current message to the one created
> > +                # in IMAP. So we just delete local message and on next run
> > +                # we'll sync it back
> > +                # XXX This could cause infinite loop on syncing between two
> > +                # IMAP servers ...
> 
> I'm afraid about this infinite loop. Can you tell more?
> 
> I understand it could be done only if two instances of offlineimap are
> running on both side.  Am I correct or did I miss something?

Yes. If we find new mail on 'local' side, we upload it to 'remote' side
and then try to find it's UID on the remote side. If we can't find it
for any reason, as a fallback we erase the mail on 'local' storage and
on next run we hope that it will be synchronized back. But if both sides
are IMAP and both IMAP servers don't allow us to find our X-OfflineIMAP
header, we'll be doing that in a infinite loop.

I hope that by implementing search for the X-OfflineIMAP by downloading
whole message header this can no longer happen. I hope that there's no
such IMAP implementation which is not capable of giving you message
headers.

-- 
	Vlad