GNOME Bugzilla – Bug 659695
Message "read count" still incorrect/inconsistant in subfolders
Last modified: 2012-07-16 16:12:58 UTC
This is an additional bug to the issue mentioned in Bug#659020. The basic symptom is that the "read count" in the mailbox list pane will give one value, which does not match with the number of bold/unread messages in the view pane. This may be multiple issues, as I see two distinct behaviors: In the first case, the latter is always larger than the former, i.e. the mailbox list pane might indicate no unread messages, but the unread messages in the view pane might include the most recent message, marked in bold as if it were unread. Selecting the message marking it as read (again) with ctrl-k will actually lower the unread message count to a negative value! In the second case, the mailbox list pane will show a higher value. For example, the subfolder may advertise 30 unread messages, but when selected, the view pane might show less and/or no unread messages. When this happens the mailbox list pane will update itself automatically. Some other things of note: * It doesn't always happen right away * It doesn't seem to happen in the main mailbox, but in subfolders * I have automatic filters moving messages into these subfolders * When the first case happens, evo's view of unread messages doesn't match outlook's opinion, even after explicitly selecting send/receive, until doing so, quitting evo, and starting it again (which usually results in the second case, which can be fixed without stopping evo). I can provide more info, or even screenshots, if necessary, just lemme know :)
I think I saw something similar too. The issue with "unread messages shown, then vanished on folder selection and reappear after the folder is updated" seems to me related to local folder cache invalidation. I usually noticed similar behaviour when I clear my local cache for MAPI account and I select the folder for the first time. I didn't notice the other thing you describe, maybe I just didn't spot the right circumstances. I'll check this after some other "bigger" changes I plan to cause to ema for 3.4.
Could you try with current git master, please? I did a commit yesterday, into evolution-data-server [1], which may fix some kinds of these errors. [1] http://git.gnome.org/browse/evolution-data-server/commit/?id=5c52fe678
How can i make a release tarball from git? I tried git-archive but thr tarbarll is missing gtk-doc.make (and others)
make dist
sean, Christoph, do you have any update for the bug ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
This problem is stil existing in the version provided in F16 evolution-3.2.3-3.fc16.x86_64. Was the proposed patch from comment 2 ever applied to any release?
Yes, the link is to evolution-data-server git master branch, the committed patch. It was committed in time of 3.3.5, thus 3.4.0 contains it. Nonetheless, this doesn't seem to be fully fixed by it, as noted at bug #559391. I believe this is not evolution-mapi fault after all, thus I'm closing this as a duplicate of bug #559391. The counts should be correct with 3.4.4+, and will probably require local cache refetch, but I'm not sure with that. *** This bug has been marked as a duplicate of bug 559391 ***