ERROR in syncfolder for (username) folder INBOX : null byte in argument for long()

chris coleman christocoleman at
Thu Apr 28 18:28:12 BST 2011

Nicolas, I fully agree.  

We use offlineimap like an IMAP'ed version of fetchmail, to two-way sync our 
remote and local mailboxes.  It is such an important process, that when 
offlineimap is dying/crashing from bad data, that's terribly frustrating.  

The current error message doesn't give me enough clear info to know, beyond a 
doubt, which row of precisely which file is corrupt.  

( The corresponding message's date/time/from/to/subject, and whether it's in the 
local or remote repository, would be very great to have, as well.  )

Bonus: A non-destructive technique to regenerate the row of bad data would be 
amazing. If it somehow could just delete the bad row of garbage, and regenerate 
it fresh without triggering any further cascading gigabytes of data upload or 
download (except maybe the single message).

Your opinons??


From: Nicolas Sebrecht <nicolas.s-dev at>
To: Sebastian Spaeth <Sebastian at>
Cc: offlineimap mailing list <offlineimap-project at>; 
Nicolas Sebrecht <nicolas.s-dev at>; chris coleman 
<christocoleman at>
Sent: Thu, April 28, 2011 1:09:24 PM
Subject: Re: ERROR in syncfolder for (username) folder INBOX : null byte in 
argument for long()

On Thu, Apr 28, 2011 at 02:54:35PM +0200, Sebastian Spaeth wrote:
> On Wed, 27 Apr 2011 23:09:36 -0700 (PDT), chris coleman 
><christocoleman at> wrote:
> > Nicolas, Sebastian, and the team:
> > 
> > Here is the log from the my first user account which is crashing from the 
> > corrupted data.  
> > This is OfflineIMAP 6.3.2
> > Python: 2.5.2 (r252:60911, Jan 24 2010, 14:53:14) 
> > WARNING: Error occured attempting to sync account username: Traceback (most 
> > recent call last):
> >     (self.diskr2l, self.diskl2r) = self._loadmaps()
> >   File "/root/nicolas33-offlineimap-v632/offlineimap/folder/", line 
> > 49, in _loadmaps
> >     (str1, str2) = line.split(':')
> > ValueError: too many values to unpack
> Yes, this looks like a corrupt UIDMaps file again. It loads the UIDMaps,
> expecting a line with one ':' but it seems to be getting a line with
> several ':' on it, which leads to the "too many values to unpack" error.
> So this is a corrupt UIDMaps file for sure. It is not encouraging to see
> that they can get corrupted repeatedly... :-(

Right. I think it's worth implementing a check for that. I'm thinking

  1) catch the exception
  2) warn, giving all sensible information
  3) ignore/skip to not abort the whole sync
  4) document this issue in the FAQ

Nicolas Sebrecht

OfflineIMAP-project mailing list
OfflineIMAP-project at

OfflineIMAP homepage:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the OfflineIMAP-project mailing list