Please push bug fix for MULTI-RESPONSE IMAP SELECT

[Lars Thalmann]

Hi,

I reported the problem of multi-response IMAP selects with offlineimap
1.5 yrs ago.  It was very happy to notice that you had fixed the
program (with a better patch than the one I wrote).  Many thanks for
that!

However, offlineimap 6.3.3 (Ubuntu 11.10) has a bug that breaks this
patch.  For some reason the variable 'maxmsgid' is wrongly set to the
first response instead of the maximum.

It would be great if someone can help to push the following fix so
that offlineimap works again for multi-responses.

--- folder/IMAP.py.orig        2011-05-01 10:22:18.000000000 +0200
+++ folder/IMAP.py     2012-01-03 14:07:13.102026996 +0100
@@ -179,7 +179,6 @@
                 for msgid in imapdata:
                     maxmsgid = max(long(msgid), maxmsgid)
 
-                maxmsgid = long(imapdata[0])
                 messagesToFetch = '1:%d' % maxmsgid;
 
                 if maxmsgid < 1:

For anyone who might be interested, the below is an example IMAP debug
log that shows that the fetch only fetch messages '1:500' when it
really should really fetch '1:2913' (using offlineimap 6.3.3 on a
multi-response IMAP server).

Folder sync [backup]:
 DEBUG[imap]:   38:33.69 Folder sync [backup] state_change_pending.release
 DEBUG[imap]:   38:33.69 Folder sync [backup] _get_untagged_response(READ-ONLY) => ['']
 DEBUG[imap]:   38:33.69 Folder sync [backup] _get_untagged_response(EXISTS) => ['500']
 DEBUG[imap]:   38:33.69 Folder sync [backup] _get_untagged_response(EXISTS) => ['1000']
 DEBUG[imap]:   38:33.69 Folder sync [backup] _get_untagged_response(EXISTS) => ['1500']
 DEBUG[imap]:   38:33.69 Folder sync [backup] _get_untagged_response(EXISTS) => ['2000']
 DEBUG[imap]:   38:33.69 Folder sync [backup] _get_untagged_response(EXISTS) => ['2500']
 DEBUG[imap]:   38:33.69 Folder sync [backup] _get_untagged_response(EXISTS) => ['2913']
 DEBUG[imap]:   38:33.69 Folder sync [backup] _untagged_response(OK, ?, EXISTS) => ['500', '1000', '1500', '2000', '2500', '2913']
 DEBUG[imap]:   38:33.69 Folder sync [backup] [async] FETCH ('1:500', '(FLAGS UID)')

Please let me know if I can be of further help in this or whether
there is something wrong with the patch.

Best wishes,
Lars


On Tue, Jun 08, 2010 at 08:10:31PM +0200, Lars Thalmann wrote:
> Hi,
> 
> It seems some servers (Zimbra?) respond to imap SELECT requests with
> multiple EXISTS lines:
> 
> ? SELECT INBOX
> * 500 EXISTS
> * 0 RECENT
> * 1000 EXISTS
> * 0 RECENT
> * 1500 EXISTS
> * 0 RECENT
> * 1567 EXISTS
> * 0 RECENT
> 
> This is a rough patch to fix offlineimap so that it handles this:
> 
> --- /usr/share/pyshared/offlineimap/folder/IMAP.py.old  2010-06-08 19:04:32.650092826 +0200
> +++ /usr/share/pyshared/offlineimap/folder/IMAP.py      2010-06-08 19:53:36.030161637 +0200
> @@ -126,7 +126,13 @@
>              try:
>                  # Some mail servers do not return an EXISTS response if
>                  # the folder is empty.
> -                maxmsgid = long(imapobj.untagged_responses['EXISTS'][0])
> +                maxmsgid = 0
> +                i = 0
> +                l = len(imapobj.untagged_responses['EXISTS'])
> +                while (i < l):
> +                    r = long(imapobj.untagged_responses['EXISTS'][i])
> +                    maxmsgid = max(r, maxmsgid)
> +                    i += 1
>              except KeyError:
>                  return
>              if maxmsgid < 1:
> 
> Would be great with feedback on whether you think this is the right
> solution or not.
> 
> Best wishes,
> Lars
> 
> 
> -- 
> Lars Thalmann, www.larsthalmann.com

-- 
Lars Thalmann, www.larsthalmann.com