crash on sync of large maildir

[Mark A. Hershberger]

Sebastian Spaeth <Sebastian at SSpaeth.de> writes:

> On Sat, 30 Apr 2011 23:14:24 -0400, mah at everybody.org wrote:
>> I've used offlineimap very successfully for a long time, but recently
>> something started happening to screw it up.
>
> Mmh, once the UID map between 2 IMAP servers gets screwed, things are
> not going to be nice with offlineimap.

I *think* I deleted all the UID map files and the entire contents of the
INBOX after I started having trouble.  My thought was that I could have
a fresh start.  If you'd like me to try again, I'd be happy to — just
point me to the correct directions for making sure I have the mapping
entirely cleared.

> The whole IMAP<->IMAP syncing really feels somewhat tacked on in a
> rather hackish way. IMAP<->Maildir is much more robust, personally I
> would advice to use that.

I'll try IMAP<->Maildir.  I was doing IMAP<->IMAP because Emacs/Gnus
support for Maildir sucked when I first set this up.

Might be time to try that again, though.

> When we fetch the message with UID 780665 from your local IMAP it
> responds with an empty message. This line is supposed to contain the
> full email message:
>> imap: Returned object from fetching 780665: ('OK', ['72967 (UID 780665 BODY[] "")'])
>
> Your mail server is serving something bogus here, it seems. Where the
> "content is: '2'" comes from, I don't know.

For what it is worth, 6.3.2 returned the offlineimap UUID header here
instead of “2”.  I'm not sure if “2” is better or not. ;)

>>     Establishing connection to tunnel:nice env MAILDIR=/home/mah/maildir/everybody.org /usr/lib/dovecot/imap.
>
> There have been changes to the tunneled authentication recently. I am
> not sure if that is resonsible for anything...

Wouldn't it be better to warn people (say, if they haven't updated their
config file with a flag that says “I REALLY mean to do this”) that the
support is not really tested than to just continue?  That way, I think
people would be more likely to report bugs at least.

> These messages have been deleted on the REMOTE IMAP server: 407, 408,
> 409, 410, 411, 412 and it tries to delete them on the LOCAL
> one.

Right.  I don't think I tried just deleting them on the REMOTE server.
I'll try that next time.

> We definitely should not fail hard here. I'd consider that a bug. Our
> only excuse is that this behavior has existed forever and we did not
> have time to fix it since the maintainer change.

Is there somewhere I can file a bug report?  Or will you just track it
otherwise?

Next, what happens when I try maildir.

-- 
http://hexmode.com/

War begins by calling for the annihilation of the Other,
    but ends ultimately in self-annihilation.