GNOME Bugzilla – Bug 685034
Read status of email is not persisted correctly
Last modified: 2012-10-30 17:50:58 UTC
Evolution 3.4.4 running on Fedora 17. The account is a gmail account configured via GOA. Evolution's settings list the account as "imapx". Evolution fails to persist the read status of my email. For example: I open evolution, and read an unread mail. The mail is marked as read after a timeout as expected. I then restart evolution. When Evolution loads the folder again, the mail is initially marked as read, but after a small delay (maybe ½ second?) the status is changed back to unread. I tried running evo from a terminal, but nothing is written there. Another observation: If I go into the settings and change the "synchronize email locally" setting for the account after I mark the mail as read, the status seems to be persisted correctly.
I can confirm this. It seems that the cancel on close cancels IMAPx's attempt to store the message flags, or something like that.
*** Bug 687058 has been marked as a duplicate of this bug. ***
"Automatically synchronize remote mail locally" does not help for me. =/
Oh, that "workaround" was worded confusingly... When the setting is changed, statuses seems to be flushed to the mail server *once*, after reading another mail the procedure needs to be repeated :) But I think Milan is on to something, because switching folder before closing evo seems to make the flags persist fine.
Oh dear, a much easier workaround than checking "automatically synchronize remote mail locally" every time: just press F9 (Send/Receive) before closing Evolution. (If switching folders works, that's cool too.)
I guess the change of option "synchronize remote mail locally" only calls the same flush as F9 or folder change or few other operations. It's only more complicated than doing the other ways.
Created attachment 227666 [details] [review] eds patch for evolution-data-server; OK, I was initially unable to reproduce this with my Yahoo! account, but then I tried with Google and it was exhibiting it. The difference is that Google supports IDLE (Listen for server changes notification in Properties), while Yahoo! does not. The IDLE stop response prevented from processing of the rest of pending requests, thus the recent changes in a folder were not properly saved. This change fixes the behaviour. You can workaround it by disabling IDLE in Properties of the account (requires restart of evolution in 3.4.x-).
Created commit db33525 in eds master (3.7.2+) Created commit 8976a4c in eds gnome-3-6 (3.6.2+)