GNOME Bugzilla – Bug 206062
summary fails to notice IMAP flags changed by another client
Last modified: 2009-12-11 05:52:59 UTC
When some other client removes a message from an IMAP folder, Evolution fails to notice that the message is gone. It continues to show the message in the summary and even in the previw pane. If you switch to a different folder and back again, the "ghost" message remains. Clicking the "Send/Receive" toolbar button does not fix things. Even quitting Evolution and restarting it does not clear out the ghost of this message that no longer exists. The only way I've found to fix things is to remove the "summary" file from the folder's local cache. That seems to force Evolution to rescan the entire folder, and thereby build a new summary without the ghost. To reproduce this problem: 1. Examine INBOX on an IMAP server using Evolution and also using some other IMAP client of your chosing. 2. Pick some message in this folder, and view that message in Evolution and also in the other client. 3. Using the other client, remove the message from INBOX. For example, move it into a different folder or just delete it in place. 4. Using the other client, expunge INBOX. So at this point, that message should be gone, gone, gone, with no remnant left behind. 5. Return to Evolution, and observe that the ghost message is still present. Switch folders and come back. Click "Send/Receive". Quit and restart. No matter what you do, that ghost message remains. My IMAP server self-identifies as "Netscape Messaging Server 4.15 Patch 6 (built Mar 30 2001)". I haven't tried reproducing this using other servers, so I don't know if this is a general issue or if it's specific to Evolution's interaction with Netscape's server.
*** bug 206323 has been marked as a duplicate of this bug. ***
It looks like somebody may have partially fixed this. I just tried clicking "Send/Receive" and Evolution did seem to pick up the fact that I had deleted and expunged a message. Quitting and restarting Evolution also worked. Switching to a different folder and back again did not, but I'm not sure that's really a big deal. However, it's not perfect. If I just delete a message and do not expunge it, Evolution doesn't notice the change. Hmmm.
I dunno some of this really sounds like an imap protocol/server issue.
I don't think that this is a server-side issue, as other clients I have do behave as expected. For example, if I am running Mozilla and Pine simultaneously, and I delete (but do not expunge) a message in Mozilla, Pine notices the change the next time it scans the folder. Evolution does not. Perhaps my other mail clients just aren't caching as aggressively as Evolution. If that's the difference, then I'd say Evolution has the bug. As a user, I have a reasonable expectation that clicking Send/Receive should completely synchronize the local view of INBOX with respect to the server. But it appears that Evolution is assuming that Deleted flags won't change behind its back, and therefore is not re-scanning INBOX as thoroughly as it should.
Ah, that's why... Pine *rescans*... that is an expensive operation to have to rescan the entire folder. If you exit Evolution and then re-open, it will have the new flags.
OK, I'm willing to accept the idea that a full folder rescan is too expensive to perform on every Send/Receive or folder switch. However, I know that IMAP servers can send unsolicited "FETCH (FLAGS ...)" replies to clients to inform them of changes to messages' flags. If my server did send such a reply, would Evolution use it? (I don't actually know if my server is sending such notifications. I should probably attach a packet sniffer and find out, but my IMAP connection is SSL, so I'd need to set up a tunnel in order for the sniffer to tell me anything useful. I can do that if it would help, but I'm feeling slightly lazy at the moment.)
OK, I set up a tunnel so that I could type cleartext IMAP protocol and read the replies directly. (I happen to speak a bit of IMAP, from my former life as a software engineer writing e-mail clients.) If I have two simultaneous connections open, and I change flags in client A, client B doesn't see the changes at all. It doesn't see them as unsolicited "FETCH (FLAGS ...)" replies, and it doesn't even see them in response to an explicit "FETCH <n> (FLAGS)" command. In fact, the server is completely happy to continue reporting the old set of flags to client B no matter what client B does. Client B can switch to another folder, come back, and it still doesn't see the flag changes from client A. It appears that there are only two ways for client B to see the flag changes from client A. First, if client B disconnects and reconnects, it sees the updates. Second, if client A makes its changes before client B eever asks for a given message's flags, then when client B does finally ask for the flags it sees the updated flags. This is all happening at the server end. It appears that the server is caching flags on a per-connection basis. That cache is pretty persistent: even switching folders or issuing CHECK commands doesn't reset it. All you can do is disconnect and reconnect. At this point I'm convinced that this really is a server issue. Evolution cannot be expected to notice that a message has been deleted if the server refuses to reveal that information even when explicitly asked. The only workaround appears to be disconnecting and reconnecting, but I don't think that's something we want Evolution to do. I'd close this bug right now, but I'm not sure what resolution to use. Is this NOTABUG, WONTFIX, or NOTXIMIAN?
and all the grief ya gave us... sheesh ;-)
[Catching up on old bugzilla mail.] Evolution actually is broken. It discards unsolicited FETCH responses. I guess maybe your server is broken too, but if it wasn't, you'd still be seeing exactly the same behavior.
*** bug 210300 has been marked as a duplicate of this bug. ***
*** bug 217148 has been marked as a duplicate of this bug. ***
*** bug 220596 has been marked as a duplicate of this bug. ***
I am using a certified server (CommunigatePro) and certified client (Mulberry) and am witnessing the same erroneous flag behavior in Evolution. By "certified" I mean that this server and client pair are widely considered to have the most accurate implementations of the IMAP protocol. I believe that the appropriate semantics are, when a user selects a new folder, or a mail check is done on the current folder, the flags of all messages in the mailbox in question should be re-checked with the server. Glancing at the IMAP spec (http://www.faqs.org/rfcs/rfc2060.html), it looks like the current FETCH HEADER that is used to refresh headers when switches to a new mailbox needs to have a FLAGS appended to it, but that's about it. Note that, if more than one client is viewing a folder, the IMAP protocol does not specify which one sees a new message as UNSEEN. We've been experimenting with modifying flags using Mulberry and Evolution (1.0.3), disconnecting and reconnecting, etc. It looks like not only does Evolution improperly check flags, but it improperly marks them as well. The only way to get things refreshed properly, in our brief testings, is to fully exit Evolution and restart.
who is CommunigatePro it certified by? I've tended to experience problems with it being non-rfc-compliant left and right.
I hereby certify that Evolution is the mostestestest accurate IMAP implementation therefor it must be so. :-) NOTABUG!! j/k, but seriously...
The problem as dan points out is that the imap code ignores unsolicited (i.e. they werent' explicitly asked for) FETCH responses, which is how any server notifies multiple clients of flag changes. Bad camel, no biscuit. Saying this depends on 16927 (imap rewrite) just to track it, as it's one of those fairly hard to fix bugs wiht the current codebase.
fwiw, this works in my IMAP4 plugin (which is not the same as the standard IMAP plugin for Evolution). you need to use --enable-imap4 with ./configure to enable it.
If you delete some mail in other mail client(say thunderbird) and then come back to evolution, restart it. I am able to see the changes with 2.2.1 version of Evolution. No need to delete 'summary'.
I don't see flag changes (Replied nor Deleted) with Dovecot, no matter what I do to refresh -- send/receive, change folders and back. A FETCH FLAGS should probably be done to update flags periodically, since it's not unsolicited information. Evolution 2.8.1 Dovecot 1.0.rc10
This bug has been fixed in 2.24.5 and later versions. This version is no longer maintained, which means that it will not receive any further security or bug fix updates. The current stable GNOME and Evolution version is 2.28. Can you please check again whether this issue still happens in Evolution 2.26 or 2.28 and update this report by adding a comment and changing the "Version" field? Thanks a lot. Again thank you for reporting this bug and we are sorry it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE in 6 weeks.
Closing this bug report as no further information has been provided. Please feel free to reopen the bug if the problem still occurs with a newer version of GNOME 2.28.0 or later, thanks.
Well, this particular problem may be gone, but if one uses OWA (the web interface) to read mail messages in Exchange, more often than not these messages will be still marked as unread by Evo that connects to the same exchange mailbox using OWA.
(In reply to comment #22) > Well, this particular problem may be gone, but if one uses OWA (the web > interface) to read mail messages in Exchange, more often than not these > messages will be still marked as unread by Evo that connects to the same > exchange mailbox using OWA. Bojan, sure, owa connector bug can be taken care separately. Please file a bug against evolution-exchange, thanks.