GNOME Bugzilla – Bug 545103
Answered flag/labels messed up?
Last modified: 2013-09-13 00:58:56 UTC
I forwarded in old evolution (trunk before db-summary) to 4 messages in evolution-list today and marked some messages from bugzilla as work (labels). All seemed fine as far as I can tell. I closed this old evolution. Then, on the other machine, I opened actual trunk, it downloaded those new messages to local store for the first time. I didn't notice any unusual thing, maybe except the new counter, folder shows the number of newly arrived mails, but these are already marked as Seen, thus the number is false. I also noticed some mails I moved to other folder are shown too, even strike-out as deleted. Anyway, closing this instance and coming back to old evo on the other machine shows me that I have most of my mails in evolution-list marked as replied, but I really do not write there so often. Also some labels in bugzilla mail folder has been duplicated to other mails. This makes my tracking of work kinda hardly-usable. But will see. Does anybody notice similar behaviour as described above? All on IMAP for me.
Milan, its sort of confusing to read for me... Can you put out in steps? What operation on what. Also evolution-list means a mail to the list or moved 4 mails to such a folder? Also are you sure, that the summary is synced to the server in the old evolution after you saw the mails there? Anyways, as usual retry, since we fixed bunch of warnings and more flag sync stuff.
That's the thing. I do not have exact steps, except of "do something in old evo, then open new evo, wait until refresh and close new evo and see the difference in old evo". There should be none difference in "old=>new=>old" in case I do nothing in "new" (just update). But it isn't. I believe the old evolution behaves correctly, it "always" did, so should be question of new evolution. All I do is on an IMAP account. I updated and recompiled eds and evo to actual trunk, namely eds 9221, evo 35858 a) I have in Inbox some messages I moved/deleted in old evo. I can see these messages in new evo, they are strikeout, but I have checked "hide deleted messages". These message were new for new evo, even Seen already when received. Tested again and when I delete something in old evo, new evo doesn't update summary properly, thus select thinks it's not deleted, but it is. b) number of unread messages just increases, not updated on the new download as well (probably same issue as a)) c) I cannot reproduce the thing with labels reliably, I do not know how it happened exactly, it just happened. Labels I marked from old evo (or had marked on the server), are copied to other messages too, but not always. I'm not sure why, maybe just updated from summary to the server? More or less, can be also question of a), though.
I checked with eds 9222, evo 35859 and it's a bit better, just adding new notes: I do not know how to describe to have that make sense :( On a first sight, it seems that the update of the summary doesn't distinguish recent and seen messages, you know, the message can be both, when I open new message and read it in old evolution and then fetch in the new evo. New evo marked the seen message as unseen and mixed counter a bit too. (I see only 6 new messages but counter shows 10; it seems you also updates counter relatively, thus after some issue it's messed, not updated by the value of the server).
Retry. I changed quite a few things in how imap syncs flags. Some how I feel it should be better wrt counts, n/w usage etc.
I have thread view turned on. Another try to describe it: a) I got 34 completely new messages in one imap folder b) go to that folder and read two messages (so the count is 32 now). c) just select other folder and go back, for tick of the second I see those messages as read, but just now then became unread again. d) read them again (I mean, select them and let timeout mark them as read). e) move to other folder and back, for a tick of the second I see some other messages as new as before, but just at the moment some of them got marked as read even I didn't read them, so the count is now 25. Now I can continue in b), getting 16. Quite good :) I think the main key is that the messages are new in the summary for this session.
Just to have this stored, I have a folder with 7 messages, marked 4 as unread, went out and back and the fifth has been marked as unread too. Watching info->flags of the offending message info showed place where it got changed: Old value = 16 New value = 0 imap_rescan (folder=0x7f008ce77bd0, exists=7, ex=0x7f0092d9b390) at camel-imap-folder.c:1018 1018 iinfo->server_flags = new[j].flags; (gdb) bt
+ Trace 204261
Created attachment 115621 [details] [review] proposed eds patch for evolution-data-server; Finally the get_matched wasn't ready for new improvements. Question: are UIDs in the order or not?
Created attachment 115623 [details] [review] proposed eds patch ][ for evolution-data-server; OK, they are not sorted, thus sort them first.
Milan, awesome....
Committed to trunk. Committed revision 9242.