Re: Faster nnimap: nnimap-retrieve-groups-asynchronous

["Bjørn Mork" <bmork@dod.no>]

Simon Josefsson <jas@extundo.com> writes:
> Bjørn Mork <bmork@dod.no> writes:
>
>> I currently use three imap servers:
>> a) IMAP4 server (InterMail vM.4.01.03.23 201-229-121-123-20010418)
>> b) Courier-IMAP ready. Copyright 1998-2001 Double Precision, Inc.
>> c) Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc.
>
> I suspect the same problem as Ilpo reported, also Courier IMAPD from
> what I recall.  I haven't debug that yet though.
>
>> The problem is that Gnus doesn't detect new mail split into a folder
>> on b) when pressing 'g'. Doing a 'M-g' on the folder will however show
>> the new mail. The funny thing is that everything works fine on server
>> a) and c). So it looks like a combination of a Courier server and
>> client side splitting is causing the problem, unless there is a
>> specific problem with the Courier version running on b).
>
> Can you find out the server versions used on server a and b?

I assume you meant b and c, since a reports the version its the
greeting above. c is running a CVS version from 2002-03-14, which
should make it 1.4.3 + some fixes. I believe b is running 1.3.5 but
haven't been able to confirm this. Is there any way to check this
remotely, or do I really have to get hold of the guy who compiled it? 

> Hm.  At first glance, it looks like it, but it could be valid
> behaviour if UIDVALIDITY changed. Could you try running with this
> patch?  Does the UIDVALIDITY change between 128- and 175-like commands
> then?  Nnimap is buggy, it should look at UIDVALIDITY as well here.
> I'll fix it.

But it doesn't make any difference in this case. With your patch:

44 STATUS "INBOX.Trash" (uidnext uidvalidity)
* STATUS "INBOX.Trash" (UIDNEXT 2 UIDVALIDITY 979914089)
44 OK STATUS Completed.
[..]
57 SELECT "INBOX"
* FLAGS (\Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen)] Limited
* 135 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 979914089] Ok
57 OK [READ-WRITE] Ok
58 UID SEARCH UNSEEN UNDELETED
* SEARCH 376
58 OK SEARCH done.
59 UID FETCH 376 BODY.PEEK[HEADER]
* 135 FETCH (UID 376 BODY[HEADER] {1380}
[snipped mail header]
59 OK FETCH completed.
60 UID COPY 376 "INBOX.Trash"
60 OK COPY completed.
61 UID STORE 376 +FLAGS (\Seen \Deleted)
* 135 FETCH (FLAGS (\Seen \Deleted \Recent))
61 OK STORE completed.
62 EXPUNGE
* 135 EXPUNGE
* 134 EXISTS
* 0 RECENT
62 OK EXPUNGE completed
63 CLOSE
63 OK mailbox closed.
[..]
73 STATUS "INBOX.Trash" (uidnext uidvalidity)
* STATUS "INBOX.Trash" (UIDNEXT 2 UIDVALIDITY 979914089)
73 OK STATUS Completed.


I also tested client side splitting with server c, the Courier-IMAP
version 1.4.3, and it does indeed look like it's working better:

36 STATUS "INBOX.Trash" (uidnext uidvalidity)
* STATUS "INBOX.Trash" (UIDNEXT 4 UIDVALIDITY 980027355)
36 OK STATUS Completed.
[..]
56 SELECT "INBOX.mail.other"
* FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited
* 94 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 1018363677] Ok
56 OK [READ-WRITE] Ok
57 UID SEARCH UNSEEN UNDELETED
* SEARCH 327
57 OK SEARCH done.
58 UID FETCH 327 BODY.PEEK[HEADER]
* 94 FETCH (UID 327 BODY[HEADER] {856}
[snipped mail header]
58 OK FETCH completed.
59 UID COPY 327 "INBOX.Trash"
59 OK COPY completed.
60 UID STORE 327 +FLAGS (\Seen \Deleted)
* 94 FETCH (UID 327 FLAGS (\Seen \Deleted \Recent))
60 OK STORE completed.
61 EXPUNGE
* 94 EXPUNGE
* 93 EXISTS
* 0 RECENT
61 OK EXPUNGE completed
62 CLOSE
62 OK mailbox closed.
[..]
77 STATUS "INBOX.Trash" (uidnext uidvalidity)
* STATUS "INBOX.Trash" (UIDNEXT 5 UIDVALIDITY 980027355)
77 OK STATUS Completed.


The only problem is that Gnus still didn't show me the new mail in the
INBOX.Thrash group. Now I'm lost again...

> The workaround is to disable nnimap-retrieve-groups-asynchronous for
> the server.

Yeah, I know. I just had a small hope I could avoid that :-)


Bjørn
-- 
You must be a real DAF driver to think that the Centre Bulletin is
always right.