From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/45135 Path: main.gmane.org!not-for-mail From: =?iso-8859-1?q?Bj=F8rn?= Mork Newsgroups: gmane.emacs.gnus.general Subject: Re: Faster nnimap: nnimap-retrieve-groups-asynchronous Date: Thu, 06 Jun 2002 16:10:46 +0200 Organization: Dundee outrageous Dock Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1023372749 22469 127.0.0.1 (6 Jun 2002 14:12:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 6 Jun 2002 14:12:29 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17Fy04-0005qH-00 for ; Thu, 06 Jun 2002 16:12:28 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17Fxyl-0002zu-00; Thu, 06 Jun 2002 09:11:08 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 06 Jun 2002 09:11:25 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id JAA07788 for ; Thu, 6 Jun 2002 09:11:11 -0500 (CDT) Original-Received: (qmail 2375 invoked by alias); 6 Jun 2002 14:10:49 -0000 Original-Received: (qmail 2370 invoked from network); 6 Jun 2002 14:10:49 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by gnus.org with SMTP; 6 Jun 2002 14:10:49 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 17FyJe-0005Y0-00 for ; Thu, 06 Jun 2002 16:32:42 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 122 Original-NNTP-Posting-Host: 148.122.193.18.dhcp.nextra.no Original-X-Trace: quimby.gnus.org 1023373962 17817 148.122.193.18 (6 Jun 2002 14:32:42 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 6 Jun 2002 14:32:42 GMT User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) Cancel-Lock: sha1:ZrYsioCR5AP3cqeh3VJFvwEuJZc= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:45135 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:45135 Simon Josefsson writes: > Bjørn Mork 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.