Offlineimap has stopped working completely

sebastian at sspaeth.de sebastian at sspaeth.de
Wed Jun 6 09:19:12 BST 2012


> Hi Sebastian,
>
> When I ran offlineimap today, I get this, which is now preventing me from
> sync'ing my e-mail alogether.  This is with the latest 6.5.4.
>
> Help!
>
> Thanks,
>   John
>
> --8<---------------cut here---------------start------------->8---
> Copy message -95 (21 of 106) LocalIMAP:[Gmail].Trash -> RemoteIMAP
> ERROR: 'NoneType' object has no attribute '__getitem__'
> Copy message -19 (22 of 106) LocalIMAP:[Gmail].Trash -> RemoteIMAP
> Thread 'Copy message from LocalIMAP:[Gmail].Trash' terminated with
> exception:
> Traceback (most recent call last):
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/offlineimap/threadutil.py",
> line 156, in run
>     Thread.run(self)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py",
> line 504, in run
>     self.__target(*self.__args, **self.__kwargs)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/offlineimap/folder/Base.py",
> line 335, in copymessageto
>     new_uid = dstfolder.savemessage(uid, message, flags, rtime)
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/offlineimap/folder/IMAP.py",
> line 592, in savemessage
>     uid = long(resp[-1].split(' ')[1])
> TypeError: 'NoneType' object has no attribute '__getitem__'


Uhh, I have not changed anything in the IMAP handling code, so I don't
know what could have happened there.

I have pushed a change to the next branch that does away with the old
Gmail workaround that we previously had to use. Can you test the current
next branch and see if you get plenty of these warnings:

savemessage: Server supports UIDPLUS, but we got no usable uid back.
APPENDUID reponse was '%s'" % str(resp))

If this is the case, we need to dig deeper into the darn imaplib2 code to
see why we don't get an APPENDUID response from it, when we really should.

Thanks for helping out on this one.

Sebastian


Commit log of the commit pushed to next:

commit 36156fa98545792649771d2599ee06a74d35169c
Author: Sebastian Spaeth <Sebastian at SSpaeth.de>
Date:   Wed Jun 6 10:02:42 2012 +0200

    Remove the APPENDUID hack, previously introduced

    As Gmail was only announcing the presence of the UIDPLUS extension
    after we logged in, and we were then only getting server
    capabilities before, a hack was introduced that checked the
    existence of an APPENDUID reply, even if the server did not claim
    to support it.

    However, John Wiegley reports problems, where the APPENDUID would
    be None, and we attempt to go this path (it seems that imaplib2
    returns [None] if there is no such reply, so our test here for "!="
    might fail. Given that this is an undocumented imaplib2 function
    anyway, and we do fetch gmail capabilities after authentication,
    this hack should no longer be necessary.

    We had problems there earlier, where imapobj.response() would
    return [None] although we had received a APPENDUID response from
    the server, this might need more debugging and testing.

    Signed-off-by: Sebastian Spaeth <Sebastian at SSpaeth.de>






More information about the OfflineIMAP-project mailing list