From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53853 Path: main.gmane.org!not-for-mail From: Gaute B Strokkenes Newsgroups: gmane.emacs.gnus.general Subject: Re: Working around IMAP server b0rk3n-ness Date: Thu, 28 Aug 2003 13:03:03 +0100 Organization: The Church of Emacs Sender: ding-owner@lists.math.uh.edu Message-ID: <87lltedm6g.fsf@srcf.ucam.org> References: <87adc3cqth.fsf@mit.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1062072336 28638 80.91.224.253 (28 Aug 2003 12:05:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 28 Aug 2003 12:05:36 +0000 (UTC) Original-X-From: ding-owner+M2393@lists.math.uh.edu Thu Aug 28 14:05:33 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19sLWv-0005Cg-00 for ; Thu, 28 Aug 2003 14:05:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19sLW0-0004tj-00; Thu, 28 Aug 2003 07:04:36 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19sLVv-0004te-00 for ding@lists.math.uh.edu; Thu, 28 Aug 2003 07:04:31 -0500 Original-Received: (qmail 60489 invoked by alias); 28 Aug 2003 12:04:31 -0000 Original-Received: (qmail 60483 invoked from network); 28 Aug 2003 12:04:30 -0000 Original-Received: from mta02-svc.ntlworld.com (62.253.162.42) by sclp3.sclp.com with SMTP; 28 Aug 2003 12:04:30 -0000 Original-Received: from belldandy ([81.100.93.186]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030828120428.CUJZ21842.mta02-svc.ntlworld.com@belldandy> for ; Thu, 28 Aug 2003 13:04:28 +0100 Original-Received: from gs234 by belldandy with local (Exim 3.36 #1 (Debian)) id 19sLUV-0007LE-00 for ; Thu, 28 Aug 2003 13:03:03 +0100 Mail-Copies-To: never Original-To: ding@gnus.org Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEWWWBTly7aGMwb+/vz9 +ffIilb///+yaCxNCwHGVC3gAAACU0lEQVR4nF2TQWvjMBBGVUGwj3WxaY/aAWNfi0zuwZPuHp0Q ob079OwYjHrsChb0s3dGctJ0ddTzm9F8lsR7WiNiWWL/flviul9Uh0NR4vY/gJUxJjOEtt/AubBy UsotRfH2DbxWE0hom3w5XJUEKis9hACt2hR4B86VDOtqTNHfgeEGvLiUN7Ddze26Dx6y1CUa+ygo NwFQm0N/BeMzCZAtNIoQrd9EhcH5mWpnztB8ZpJBlH23jaAbuE4EhZ2Bam0TeJ0DRMCKVP6CegWk q4z2TVFUx0946FOPcSe9ELE3rSHAj15rBuddS0C4BGyAutfpVAQkKdZOQiwMMIHxlUDrgeej5Ns7 I/ccSWNBLda1XwYBEG1Qswy1yXJf879nA4cjkNI0H+FzoUyuRodPA5eqZwFONG34i30ccOxeKFUy flNe1szqsgLdvXwKCj6zjTXODHV9M46gZPCLlYKCGTYO8S0aOAvJzRfD0w+1XcGIsxLUw/sYl5sM 9n0yjkoSUDOByrijwRRiAq13NhqLJYB3ACazrgN2bIwanyJQKXhHAJPRPQruEaCJP2Shy4DJ2As+ FQjJZH7AZIy6w0pQiiRYAh8nTEZHYDfRqSDeB5OXq4EEcAC4NocvoBl4+n1cyl54nyLRNA3iIwRP wNGFOK1g1Gz8jNfaCjdtqJLm2LXuqMc+50cDIJQpr6X0OHa4X58ULAw03QbRd7GUiG/K04mj0bNB xQhwJkEsJiZ1Bbgb6CnF79cBE+jwF91qniOCP3fghUFKxOShjIATw/wOfIQTg39LpFHtxhlKywAA AABJRU5ErkJggg== In-Reply-To: <87adc3cqth.fsf@mit.edu> (David Z. Maze's message of "Fri, 27 Jun 2003 14:34:34 -0400") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53853 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53853 On 27 jun 2003, dmaze@mit.edu wrote: > When using Gnus with an IMAP mail-source, it goes through, reads one > message at a time, sorts them away, and then tries to do a bulk > delete of all of the messages it's read. This is all fine and > within the bounds of the IMAP spec; unfortunately, not all software > is. I somewhat regularly wind up using an imtest binary with a > 500-byte line limit, and if I get around that, the local server has > a 16K line limit, which I do run into with enough mail. > > It'd be nice if there was a switch or fallback mode or something > such that Gnus didn't always lose in exciting ways when it hit this. You're not alone, if it makes you feel any better. I have a similar problem every morning when I try to get ~500 new messages. Gnus constructs a line of ~2000 bytes; the process then hangs indefinitely. I haven't quite tracked down what's going wrong, but the prime suspect is uw-imapd not being able to cope with long lines (we all know how robust c-client and friends are in that respect) with some sort of openssl / emacs sub-process brokenness as a more distant second. Usually I just run fetchmail once every morning. > The "I'm away for a week so it's sure to die, slow and correct is > better than fast and broken" patch is: > > Index: mail-source.el > =================================================================== > RCS file: /usr/local/cvsroot/gnus/lisp/mail-source.el,v > retrieving revision 6.36 > diff -u -r6.36 mail-source.el > --- mail-source.el 13 May 2003 22:58:29 -0000 6.36 > +++ mail-source.el 27 Jun 2003 18:29:58 -0000 > @@ -1005,9 +1005,10 @@ > (nnheader-ms-strip-cr)) > (incf found (mail-source-callback callback server)) > (when (and remove fetchflag) > - (imap-message-flags-add > - (imap-range-to-message-set (gnus-compress-sequence remove)) > - fetchflag nil buf)) > + (dolist (uid remove) > + (imap-message-flags-add > + (imap-list-to-message-set (list uid)) > + fetchflag nil buf))) > (if dontexpunge > (imap-mailbox-unselect buf) > (imap-mailbox-close nil buf)) > > ...but I don't actually want that all the time. This may help: *** mail-source.el.~6.38.~ 1970-01-01 01:00:01.000000000 +0100 --- mail-source.el 2003-08-28 12:42:48.000000000 +0100 *************** *** 1006,1011 **** --- 1005,1011 ---- (nnheader-ms-strip-cr)) (incf found (mail-source-callback callback server)) (when (and remove fetchflag) + (setq remove (nreverse remove)) (imap-message-flags-add (imap-range-to-message-set (gnus-compress-sequence remove)) fetchflag nil buf)) What's going on here is that remove is a list of message numbers that should be expunged. The imap-range-to-message-set / gnus-compress-sequence combo is supposed to create a compact representation using the imap range syntax (i.e. "1:5" rather than "1,2,3,4,5"). However, gnus constructs remove by repeatedly pushing message numbers on to it--and since gnus fetches messages in sequence, the list of message numbers will be in reverse order, which defeats gnus-compress-sequence ("5,4,3,2,1"). This won't help you much if the message numbers are not continuous, but it's a start. -- Gaute Strokkenes http://www.srcf.ucam.org/~gs234/ I'm DESPONDENT... I hope there's something DEEP-FRIED under this miniature DOMED STADIUM...