From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/59001 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: possible imap.el bug Date: Tue, 26 Oct 2004 22:07:52 +0200 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <4nwtxtf84q.fsf@lifelogs.com> <4nfz4gc99o.fsf@lifelogs.com> <4nzn2napoz.fsf@lifelogs.com> <4n7jpranuj.fsf@lifelogs.com> <4nsm8f956n.fsf@lifelogs.com> <4nsm8fcr00.fsf@bwh.harvard.edu> <4nvfd7ubzv.fsf@lifelogs.com> <4nr7nmipee.fsf@bwh.harvard.edu> <4n3c01sen4.fsf@lifelogs.com> <4ny8htmk2d.fsf@lifelogs.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098821404 14725 80.91.229.6 (26 Oct 2004 20:10:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 26 Oct 2004 20:10:04 +0000 (UTC) Original-X-From: ding-owner+M7542@lists.math.uh.edu Tue Oct 26 22:09:47 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13] ident=mail) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CMXda-0008Hk-00 for ; Tue, 26 Oct 2004 22:09:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1CMXcZ-0002Uv-00; Tue, 26 Oct 2004 15:08:43 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1CMXcR-0002Up-00 for ding@lists.math.uh.edu; Tue, 26 Oct 2004 15:08:35 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1CMXcN-0007oW-Mt for ding@lists.math.uh.edu; Tue, 26 Oct 2004 15:08:31 -0500 Original-Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by justine.libertine.org (Postfix) with ESMTP id 23D303A0034 for ; Tue, 26 Oct 2004 15:08:25 -0500 (CDT) Original-Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.1/8.13.1/Debian-15) with ESMTP id i9QK8FpO004504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Tue, 26 Oct 2004 22:08:22 +0200 Original-To: "Ding Mailing List " X-Hashcash: 1:22:041026:ding@gnus.org::6e08d2d4357f7c0a:76af20 In-Reply-To: <4ny8htmk2d.fsf@lifelogs.com> (Ted Zlatanov's message of "26 Oct 2004 14:05:30 -0400") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on yxa-iv X-Virus-Status: Clean Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:59001 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:59001 "Ted Zlatanov" writes: > On Tue, 26 Oct 2004, jas@extundo.com wrote: > >>> Does imap-open have to take a buffer argument? >> >> If not, it will create a new unique one. I think it is better to name >> the server " *nnimap* foo", to mimic how nntp do things. >> >>> I would make it always create the buffer, to be safe, and because >>> reusing the old buffer has no obvious (to me) benefit. >> >> Passwords, stream preferences, and possibly more useful data, are >> stored in the buffer. Those can be costly to discover again. >> Especially since IMAP servers typically throw you out after 30 >> minutes. > > Yes, but when it doesn't work that's tough to defend :) Right, although is anyone but you seeing this? It could be some weird interaction with some customization. Anyway, it doesn't seem right to change something without knowing what was wrong in the old code. On the other hand, if you can come up with a patch that works for you, and seem harmless, and works for others, I guess there is no major reason not to apply it, although I feel a bit uneasy about such changes in general. > I think that get-buffer-or-create will do the right thing anyhow based > on the server name in imap-open, so if the buffer already exists it > will be selected correctly. I'm not sure. imap-open name the buffers after the network address, not after the virtual server name. Imagine: (setq gnus-secondary-select-methods '((nnimap "foo" (nnimap-address "mail")) (nnimap "bar" (nnimap-address "mail")))) Where, for example, "foo" and "bar" could map to different user names in ~/.authinfo. Then there would be a collision of buffer names, since imap.el would pick the same buffer for both servers. Only nnimap.el have the virtual server name, that is why it create the buffer. Which must be unique among nnimap servers, so it can be assumed to correspond to the same server later on. Network addresses aren't unique enough. > In general, I don't understand why buffer > names are stored in the nnimap-server-buffer-alist instead of simply > generated on the fly. If that buffer exists already, great. If not, > it's no problem either. The parameter to imap-open may be a "purpose" > parameter like 'nnimap, which can be used in making the buffer name > string, but there should be no chance for passing an incorrect buffer > as is happening now. Is nnimap passing the incorrect buffer to imap-open? >>> At some point, it's called with nnimap-server-buffer set to the >>> wrong buffer but I don't know where. I do know it happens when many >>> articles are moved sequentially between IMAP servers. >> >> Maybe the problem is in gnus-move.el? >> >>> I'll keep investigating, but if we can eliminate the buffer argument >>> to imap-open I think that would make life much easier. >> >> Perhaps you could modify your local copy, temporarily? If some code >> is using the wrong buffer, perhaps renaming it will somehow trigger >> the bug more easily. > > I'm not sure what you mean here, what should I debug? You could modify nnimap and imap locally, to generate buffer names on the fly, to see if that solve your problem.