Problem syncing mail - crash

[chris coleman]

I agree with Sebastian.  Fix the bug (x-offline-imap header inserted at invalid location based on incorrect assumption) with the use of the python email module. Avoid reinventing the wheel with the same code that is exposed and vulnerable to being changed and breaking in the future.

And keep the local copy when receiving UID 0, a duplicate is annoying but it's not a big deal vs. data loss.  There are command line tools and plugins for the mail clients, to delete duplicates quickly and easily.  Data loss could be far worse than having to run a tool or plugin.

Chris



________________________________
Sebastian Spaeth <Sebastian at SSpaeth.de> wrote:
On Sat, 23 Jul 2011 15:48:20 +0200, Vladimir Marek <Vladimir.Marek at Oracle.COM> wrote:
> > 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. I see that my "optimizatons" broke
something that used to work. Thanks for the bisection.

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"
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.

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

Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110808/5a778da9/attachment-0003.html>