Re: possible imap.el bug

[Simon Josefsson <jas@extundo.com>]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> On Mon, 25 Oct 2004, jas@extundo.com wrote:
>
>> It looks fine.  I wonder why it hasn't been discovered before.
>> Perhaps it actually will solve other hard-to-debug bug reports.
>
> I still get the wrong buffer associated with a server, it just doesn't
> happen many times now.  I suspect this line:
>
>   (if (not (imap-open nnimap-address nnimap-server-port nnimap-stream
> 		      nnimap-authenticator nnimap-server-buffer))
>
> in nnimap-open-connection.

I have seen a new problem: when I open a server, it is immediately
denied, but if I try to open it again, it works fine, and it appears
to be re-using the server buffer created by the first server open.
Maybe some return value was accidentally changed to nil by your patch,
somehow?

Requiring two server open attempts is annoying; if I compose a long
message and the IMAP server kick me out, then the GCC fail.

> 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.

> 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.