GNOME Bugzilla – Bug 317755
IMAP flags are not regularly synch'd with server
Last modified: 2009-02-08 05:01:46 UTC
Please describe the problem: Currently, IMAP flags (read, answered, deleted) are not synch'd as part of the normal email synch procedure that occurs by default every 10 minutes. Instead, I believe they are synch'd only in specific circumstances (e.g. on expunge or when a folder view is changed). This works poorly for people like me. I leave evolution open 24/7 on my home machine. When I get up, I read new emails and delete a bunch of them. When I go to work, I ssh in and start pine to see if new email has arrived. But none of the flags indicating which emails I have read, answered, and deleted at home are set. Please sync flags whenever email is synch'd. Steps to reproduce: 1. Open evolution. 2. Mark an email as deleted. Don't expunge. 3. Go to a different computer and oper another email client. 4. Look at email flags. Actual results: Deleted emails are not marked as such in the second client. Expected results: Deleted emails are marked as such in the second client. Does this happen every time? Yes. Other information:
+1 on this. In my case, fairly regularly I see situation where Evo (2.4.1, using the IMAP4 provider) won't flush the flags on exit either. Ie: 1. Start Evolution, access INBOX 2. Delete/mark/reply to a message. Flags update in Evo's local view 3. Quit Evo. 4. Restart, access INBOX, flags are incorrect.
David: Verify in recent stable release evolution 2.6.2. Tried reproducing in evo 2.6.2, bug is not reproducible. If reproducible in 2.6.2 as well paste CAMEL_VERBOSE_DEBUG=1 traces of evolution, remove if any sensitive information is present. oa: imap4 is experimental, better to use imap.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information Poornima asked for (also see http://www.gnome.org/projects/evolution/bugs.shtml for more information). Thanks!
I would like to reopen this bug. The same issue exists for me, and it makes using evolution difficult. At the very least, the IMAP \Seen flag should be set immediately (or on next sync) when the message is marked as read. Flags should always be in sync with the server so other IMAP connections have correct information (esp for \Seen). Expunging or changing folders in evolution is currently the only way I know to sync up these flags, but this should not be required. For many users, these actions are rare.
nicholas: which version do you use?
Oops, left that out. I am using Evolution 2.8.1 in Gnome 2.16.1. Distro is Ubuntu 6.10 (edgy).
I'm using latest evo 2.12.0 With GNOME 2.20 and I also have this problem - flags are synchronized only on expunge and on exit (and apparently sometimes, but not always, when I change folders). This problem makes it very difficult to use evolution in coordination with other "always on" clients, such as mobile devices and mail clients on other computers (also multiple evolution instances on different computers). Currently the way I use evolution is that after any sequence of mail actions in a folder, I hit "Expunge". This is rather manual and evolution should sync impending flag modification actions every time it does mail sync.
iirc syncing also takes place when switching the folder, just fyi
Using evo 2.10 and EDS 1.12 I notice that the labels ("work", "to do", ...) don't seem to be synced either, using an IMAP server. I think these rely on the same processing, since they are IMAP flags $Label1, $Label2, etc. One possible reason is that I had evolution open on two different machines. Is syncing supposed to be 2-way? With multiple simulatenous clients (whether evolution or something else) keeping things in sync is tricky, since simply writing the client state to the server will a) miss changes from other clients and b) overwrite changes from other clients. Ross
I reported a similar bug some years ago, but it was closed by fejj, stating round-trips to the server as the reason. In this day and age, this is not an excuse. ALL other mail clients do this, pine, thunderbird, you name it. This is the only reason I use thunderbird and not evolution as mail client. (And I even contributed code to evolution pre-1.0) Please fix!
Created attachment 109923 [details] [review] proposed evo patch for evolution; I would expect to upload my changes on the server also when doing refresh on the particular folder, so I added it there too. About labels: it was fixed recently, see bug #521015
Milan, Your patch seems fine to me. But typically, the flags syncs should be more frequent than the refresh interval. I would expect it to sync every minute or so. You need to do camel_store_sync for all remote stores at a minute interval or so on a mail thread. The sync code is clever enough to sync only if it is dirty.
Do you think about new account specific option like for refresh or about new common option for all types? I'm fine with both, so asking. And from the implementation side, I suppose to extend mail-send-recv.h/.c files and keep the above patch applied, because it should be there as well.
Milan, you don't have to extend mail-send-recv. Just make it a back-ground m-t. It should be totally trans to the user IMO. Ideally we should do it on click, but thatz too much of n/w congestion. So we are clubbing and doing it at chunks/intervals.
Created attachment 110107 [details] [review] proposed evo patch ][ for evolution; Done as suggested. I kept the upload code for refresh too.
Few more issues When camel_application_is_exiting is set, lets not call sync. Now you gonna get lots of Crash on Quit issues: You access mc->priv in the done function. Im sure that when quitting this is gonna cause issues for you. Make sure that the finalize/dispose doesn't gets called or starts till the thread exits.
Created attachment 110162 [details] [review] proposed evo patch ]I[ for evolution; It wasn't as hard as I thought, the mechanism is there already with 'quit_count'. Changed also the first thing you mentioned.
*** Bug 321608 has been marked as a duplicate of this bug. ***
Seems better now. Commit it to trunk
Committed to trunk. Committed revision 35552.
could the fix be backported to the current stable release by any chance?
It doesn't change UI, and as far as I know neither break any freeze, so maybe it can. Srag?
*** Bug 433816 has been marked as a duplicate of this bug. ***
Any news on backporting the fix?
2.22.3 is out long back and it missed it. No more stable releases afaik.
I can confirm this in 2.22.3.1 in Ubuntu 8.04.1
*** Bug 321168 has been marked as a duplicate of this bug. ***
I'm still seeing this problem in Evolution 2.24.1-0ubuntu2 on Ubuntu Ibex. If I leave Evolution running on one machine, I see deleted messages "come back from the dead" when using Thunderbird and mutt on other machines. Please fix.
Created attachment 123980 [details] [review] Proposed patch Milan, this might be a simple approach with disk summary. If the viewed or any folder has changes, it does sync from there. You don't have to do store sync as your patch. I have been using it for 2 weeks or so and its fine. What do you say Milan?
OK, after some discussion on IRC, makes sense.
*** Bug 459041 has been marked as a duplicate of this bug. ***
Still a problem as of 2.24.3. Was the proposed patch committed or should the bug be reopened?
The last patch is in, within this commit: http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=9827
It is checked in with 2.24.4