<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>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.</span></div><div><span><br></span></div><div><span>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.</span></div><div><br></div><div>Chris</div><div><span><br></span></div><div><br></div><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "><div style="font-size:
12pt; font-family: 'times new roman', 'new york', times, serif; "><font size="2" face="Arial"><hr size="1">Sebastian Spaeth <Sebastian@SSpaeth.de> wrote:</font><b><br></b>On Sat, 23 Jul 2011 15:48:20 +0200, Vladimir Marek <<a ymailto="mailto:Vladimir.Marek@Oracle.COM" href="mailto:Vladimir.Marek@Oracle.COM">Vladimir.Marek@Oracle.COM</a>> wrote:<br>> > I ran git bisect to find exactly when this started happening. It worked<br>> > in the most recent release (6.3.3), and stopped working with this<br>> > commit:<br>> > commit e20d8b967942934ddbf4659b5ec328a9a18da6bc<br>> > Author: Sebastian Spaeth <<a ymailto="mailto:Sebastian@SSpaeth.de" href="mailto:Sebastian@SSpaeth.de">Sebastian@SSpaeth.de</a>><br>> > Date: Thu Mar 24 17:45:21 2011 +0100<br>> > <br>> > Remove upload neguid pass from sync logic<br><br>Hi there, I am back from my holidays. I see that my "optimizatons"
broke<br>something that used to work. Thanks for the bisection.<br><br>Perhaps I broke the behavior because I was ignorant of<br>that FAQ entry that states that we will delete the local Mail if the<br>server returns UID 0. :-)<br><br>I know it's the documented behavior, but is this really what we should<br>be doing here? If the server returns UID 0, something has gone wrong and is<br>bad. Perhaps the IMAP server responded "OK, I just deleted your uploaded<br>Mail MUAHAHAHAHA"<br>Should we really be deleting the local Maildir version of that mail<br>then? Only if we are really 100% sure that it uploaded correctly and<br>that we'll get it back on the next sync! Are we sufficiently certain and<br>happy with that strategy? Or do we want to risk duplicates rather than<br>potential data loss? I am not so sure.<br><br>Anyway, I guess the underlying reason why the search failed is that<br>offlineimap inserted the header at the wrong spot, and that was a
real<br>bug (<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482557" target="_blank">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482557</a>). Thanks<br>for the other patch fixing it. I wonder though, if we shouldn't simply<br>throw the mail file at pythons email module and add the header via that<br>one, rather than manually fudging the mail content with<br>regexes. Personally, I'd feel more comfortable with that approach, even<br>if the performance might suffer (but then our bottleneck will always be<br>network performance anyway, so we might be fine).<br><br>Sebastian<br><br></div></div></div></body></html>