Sam,
I've been having some problems with a recent version of the Evolution
MUA, as have a lot of other folks, and Milan Crha, one of the Gnome
maintainers of Evolution has been looking into it. I sent him a log
file from Evolution, and here's his response. This looks like a timing
issue, and since he asked me to let you know about it (since it _may_
be a courier-imap issue) I'm forwarding his comment on to you. The
conversation is at
<https://bugzilla.gnome.org/show_bug.cgi?id=767564>
I'm sending this on to you since the bug shows up when Evolution is
conversing with my courier-imap server at FMP, and Milan suggested I
bring you in on the discussion.
My guess is that this is an Evolution problem since others, on other
forums, report it with other IMAP servers, but I thought you might be
able to shed some light on it. Please direct replies to Milan, whose
address is in the CC, or at least CC him, so as to get me technically
out of the middle.
The version of the Courier imapd in use on this server is 4.9.1-
ubuntu4. I'm CCing Milan and the Ubuntu maintainer of the Courier
suite.
> Comment # 9 on bug 767564 from Milan Crha
> (In reply to Milan Crha from comment #7)
> > I suspect that the server has some connection-state cache and when one
> > connection knows about a newly received message, then another may not always
> > know about it, at least not until the client side of that connection asks
> > for an update.
>
> I just verified it, by opening two connections to the server, opening the
> destination folder in one of them, then copying a message to that folder from
> the other connection. Asking for the message flags also returned no data.
> Simply invoking NOOP and then issuing the same FETCH command makes it work.
> Thus it's something on the server side and the fact that the server doesn't
> like quick connection "switching" (I do not know how to better name it, even
> it's not 'switching' in the usual meaning).
>
> (In reply to fmouse from comment #8)
> > Sam Varshavchik of Double Precision is the developer
> > of courier-imap and is very forthcoming with information on all parts of the
> > Courier suite - if it matters.
>
> Nice. Let him know about this bug report and my reproducer steps:
>
> 1) open terminal A and connect to the IMAP server, issue commands:
> A login user password
> A select Inbox.sub
> 2) open terminal B and connect to the IMAP server, issue commands:
> B login user password
> B select inbox.sub2 // this is different folder than the connect A has
> 3) issue in terminal A:
> A copy 1 inbox.sub2
> * say it says the new UID of the copied message 1 is 2
> 4) issue in terminal B:
> B UID FETCH 2 (RFC822.SIZE RFC822.HEADER FLAGS)
> * nothing is returned (the server returns immediately:
> "B OK FETCH completed."
> without any data (I know this doesn't return message body, but it's only
> a detail)
> 5) issue in terminal B:
> B NOOP
> B UID FETCH 2 (RFC822.SIZE RFC822.HEADER FLAGS)
>
> Only now the headers are properly received. The NOOP also claimed here:
> * 2 EXISTS
> * 0 RECENT
> B OK NOOP completed
>
> From this I suspect the connection state on the server side was not updated
> after the copy, until the NOOP was issued. I do not know whether it's a bug on
> the server side, maybe not.
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com| -- Hiram W Johnson
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
