Red Hat Bugzilla – Bug 1024131
Evolution sometimes flushes entire cache of IMAP+ subfolder, resulting in zero messages
Last modified: 2013-11-05 06:32:45 EST
Description of problem:
This happens almost every time on suspend resume. All the folder on IMAP server (dovecot running on F-19) vanish. It also causes defaults to fail to local folders - really annoying.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Suspend (IMAP+ account configured).
3. Folders vanish. Restart of Evo required.
Did not happen until recently.
That Gnome bug says fixed. That's not true for 3.8.5.
I have also been seeing this in recent F19 evolution (looking at yum.log, possibly since evolution-data-server-3.8.5-5.fc19.x86_64). Always on suspend and resume, possibly at other times.
In the same time frame I've been experiencing other regressions which, in combination, are nigh on making evolution unusable. I'm currently seeing ~20 "Unknown background operation" tickers, and have also been seeing lots of downloading messages for offline and updating/refreshing folders lists. They frequently don't clear for tens of minutes until I have to kill evo. These do not just occur after suspend/resume, but periodically (and anecdotally more reliably shortly after suspend/resume).
Looking at the upstream bug it seems like these could also be issues around re-indexing and caching? Does this seem likely, or should I file a separate bug?
All the above problems (including vanishing folder in the original report and my secondary issues in comment #2) so far appear to be resolved by reverting, via yum downgrade, to:
Thanks for a bug report. What seemed to fix an issue for one person doesn't seem to fix it for others, thus I'll revert the patch from 3.8.5-5 for now. Upstream bug mentions that 3.10.0-1 has this fixed properly (it's part of Fedora 20), thus let's keep the fix for it, rather than chase all the changes between 3.8.5 and 3.10.0 and pick only those relevant.
I mark this as a duplicate of an older bug, just to cover more people.
*** This bug has been marked as a duplicate of bug 1022750 ***