Problem syncing mail - crash

[Vladimir Marek]

> > > I ran git bisect to find exactly when this started happening. It worked
> > > in the most recent release (6.3.3), and stopped working with this
> > > commit:
> > > commit e20d8b967942934ddbf4659b5ec328a9a18da6bc
> > > Author: Sebastian Spaeth <Sebastian at SSpaeth.de>
> > > Date:   Thu Mar 24 17:45:21 2011 +0100
> > > 
> > >     Remove upload neguid pass from sync logic
> 
> Hi there, I am back from my holidays.

Good for us, bad for you :)


> Perhaps I broke the behavior because I was ignorant of
> that FAQ entry that states that we will delete the local Mail if the
> server returns UID 0. :-)
> 
> I know it's the documented behavior, but is this really what we should
> be doing here? If the server returns UID 0, something has gone wrong and is
> bad. Perhaps the IMAP server responded "OK, I just deleted your uploaded
> Mail MUAHAHAHAHA"

In the current code return 0 is used when header was not found (for
example in savemessage_searchforheader). I was searching the IMAP rfc
for definition of UID, and I only found that it says to be ascending
numbers. So we can't distinguish if 0 is 'not found' or UID 0.

Second, we are using SEARCH and FETCH to locate the message. If IMAP
server response 0 for those commands means "I deleted the messages", I'm
inclined to say that users of such IMAP server deserve to loose their
mail :)


> Should we really be deleting the local Maildir version of that mail
> then? Only if we are really 100% sure that it uploaded correctly and
> that we'll get it back on the next sync! Are we sufficiently certain and
> happy with that strategy? Or do we want to risk duplicates rather than
> potential data loss? I am not so sure.

Well, we called APPEND beforehand and it returned OK. That sounds pretty
assuring to me.




> Anyway, I guess the underlying reason why the search failed is that
> offlineimap inserted the header at the wrong spot, and that was a real
> bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482557).

Not really, or only in some cases. The server I am using is not capable
of locating the message via SEARCH unless we search From: To: Cc: or
other 'common' headers. I posted separate patch to handle my situation,
which tries to download all mail headers and parse them via regular
expression.


> Thanks for the other patch fixing it. I wonder though, if we shouldn't
> simply throw the mail file at pythons email module and add the header
> via that one, rather than manually fudging the mail content with
> regexes. Personally, I'd feel more comfortable with that approach,
> even if the performance might suffer (but then our bottleneck will
> always be network performance anyway, so we might be fine).

Can't comment on that as I don't know python libraries, but any
code duplication is bad generally.

-- 
	Vlad