GNOME Bugzilla – Bug 221894
[RFE] configurable IMAP cache
Last modified: 2012-01-30 12:38:37 UTC
Package: Evolution Priority: Wishlist Version: 1.0.2 Synopsis: [RFE] You should be able to specify whether or not Evolution caches message headers. Bugzilla-Product: Evolution Bugzilla-Component: Mailer Description: In outlook express you can specify whether or not it should cache the message headers locally when using IMAP. Evolution should do the same. I access my mail via a Cyrus IMAP server running locally. I do this so I can access my mail from elsewhere on the network (windows box etc). There is little benefit (in fact it slows things down) in having Evolution cache all the message headers in $HOME/evolution. It also wastes disk space. I would like the ability to specify per mail folder (or globally per account) whether or not to syncronise and cache mail headers. Thanks.
Comments on this?
Another thing I hate about Evo-mail is that when I drag and drop a message from my IMAP INBOX to a folder Evo insists on fetching all the mail headers for the target mailbox. This can take an age when there are 1000's of messages in that mailbox. This behaviour is probably related to the above.
that's because of the way the abstraction layer works, there's really not much we can do about that short of a complete rewrite (which ain't gonna happen anytime in the forseeable future). That said, I can't say we'll even implement "Don't cache headers locally" but I'll leave it around for those people who care about it and decide they want to contribute to Evolution by submitting patches and whatnot. There *are* plans to fix Evolution so that we don't cache local copies of the message bodies though. Which at least solves part of your complaint.
I'd like to add to this myself. I too would like to see the ability to control whether or not headers are cached locally. We use an IMAP server in our institution, and I'd like to be able to turn off local header caching as it causes me to constantly overrun my home directory quota. I have several *large* IMAP folders I watch, and the forcing of local header caching makes for a very large evolution directory, which in turn forces me to constatnly go and delete some of the cache directories to be able to stay under my alotted quota. I'd like to see Evolution used a whole lot more in our University by faculty and staff who use Linux (and there are a number of those), and the introduction of the Exchange connector will help fuel that, but I can see this getting in the way of that.
another problem is that the cache is ... - currently not a cache at all, its just a copy of everything you ever downloaded (and not deleted). - used directly for offline mode the last point is a bigger problem to solve, and surprise surprise, another reason that offline mode shoudl be in camel and not in the shell. i guess this depends on the imap rewrite anyway as itd be a pretty major change to the current code.
Is any progress here? Local cache of all message bodies is a really huge problem. It causes quota to overflow. For example I have 500 MBytes in evolution directory: [olaf@venus mail]$ du -s /home/olaf/evolution/mail/imap 498112 /home/olaf/evolution/mail/imap This is really crazy. This also causes backups to grow enormously. I have bumped it from WISHLIST to MINOR.
we no longer "cache" headers, so that eliminates some of the complaint at least, btu we still retain a copy of each message viewed. as a workaround until we implement this, you could setup a cron job to go thru th evolution imap cache folder tree and delete the cached message files.
Please provide an example cron job.
`man 5 crontab` and `man crontab`
I know how to use cron. I was meaning what do we need to purge from evolution's user imap cache? Please explain the process for purging the mail/imap folders. Can we just safely delete the 1234. files? What about the summary files? etc etc.
<uid>.* files may be deleted safely. you *could* delete the summary files too, but I wouldn't recommend it. deleting them would cause evolution to re-scan the folders for message structures, flags, headers, etc.
It will be also good to be able to configure the max size of the cache.
An example, correct me if I'm wrong: find ~/.evolution/mail/imap/jwarnier@beeznest.net/folders/INBOX/ -type f -name "*." -exec rm {} \; You can of course filter it better if you want.
Is it safe to delete ~/.evolution/mail/imap/<account_name>/folders/* ? Will evolution recreate the "cache" for that account if it's missing?
I deleted ~/.evolution/mail/imap/* and evolution recreated everything without complaning. Perhaps evolution could include a feature that would do this from within the program in a user-friendly way? Some ideas: * Allow deleting the cache for individual accounts. * Calculate the hard drive space freed by deleting the cache. * Allow setting a maximum cache size and automatically deleting old items when the size exceeds this limit.
Has this progressed? I don't want to have all my private emails sitting on my laptop just in case anything happens to it. To me, security is more important than being able to read email offline.
(In reply to comment #16) > I don't want to have all my private emails sitting on my laptop just in case > anything happens to it. To me, security is more important Encrypt your harddisk.
(In reply to comment #17) > Encrypt your harddisk. Exactly. Or close up permissions on your home directory. Or just use web mail. Once another user gains access to your home directory you've already lost. Closing as WONTFIX.
(In reply to comment #18) > Closing as WONTFIX. Hmm. Robin's comment about security is a separate issue than this bug. This bug was about being able to configure the caching behaviour of Evolution, primarily for disk space and performance reasons. Security was not the issue. If the RESOLVED, WONTFIX came because of the security issue, then I propose that this bug be reopened. Unless the original proposal is also rejected.
Oh yes, and also note the earlier comment: Jeffrey Stedfast [developer] 2004-05-20 20:18:42 UTC [...] as a workaround until we implement this, you could setup a cron job to[...] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Perhaps something has been implemented already, or is something still being planned?