After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 663292 - Local cache vanished with deleted items
Local cache vanished with deleted items
Status: RESOLVED FIXED
Product: evolution-mapi
Classification: Applications
Component: Mail
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: evolution-mapi-maint
evolution-mapi-maint
Depends on:
Blocks:
 
 
Reported: 2011-11-03 07:33 UTC by Milan Crha
Modified: 2011-11-08 10:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Milan Crha 2011-11-03 07:33:09 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=750877

Not sure if this is an issue with evolution or evolution-mapi.

There's a process that runs on occasion that displays in the status bar at the
bottom that basically says "removing deleted messages from the cache". The
process sits there and thrashes the hard disk and when it eventually finishes
it has removed masses amount of email that it shouldn't have as part of the
process. Invariably the mail that remains in the local cache from the exchange
server dates back a couple of years. To get my email back I need to restart
evolution where it then proceeds to take ages and downloads all the messages
again from the server which also takes masses of CPU and time and it'll often
be 30+ minutes before I get back a view of my current and recent mail.

This use to happen with evo 3.0 on Fedora 15 too so its not exactly new to
F-16.

evolution-NetworkManager-3.2.1-2.fc16.x86_64
evolution-mapi-3.2.1-1.fc16.x86_64
evolution-3.2.1-2.fc16.x86_64
evolution-data-server-3.2.1-1.fc16.x86_64
evolution-help-3.2.1-2.fc16.noarch
Comment 1 Milan Crha 2011-11-08 10:17:44 UTC
This should be fixed with commit 98a632f in evolution-mapi git master (3.3.2+).

I did there a different approach of folder summary fetching. The disadvantage is that the summary for each message will be downloaded again, but after the initial reload (which should be quicker now), everything should work as expected. The requested time for summary fetching is about 2/3 of the previous approach - it takes less than 1 second per message for my test folder. It's still slow, but when the offline handling will be done fully, the message will be downloaded only once, and mostly with the same time as the folder summary (+ time to download attachments).