GNOME Bugzilla – Bug 356456
pop cache never gets purged
Last modified: 2010-06-01 10:59:56 UTC
Every time I receive a new email, a copy is placed into ~/.evolution/mail/pop/<email-address>@<pop-server>/cache/<nn>/, and never gets deleted, even if I delete messages and empty the trash. There are currently 6001 files in that directory, using 65 MB of disk space. I just sent myself another mail and counted again, and there were 6002 files. Then I deleted the new message, emptied the trash, and there were still 6002 files in the pop cache. I checked to see how many 100 day old files there were: $ find . -type f -mtime 100 | wc -l 32 $ find . -type f -mtime 100 | head -3 ./19/GmailId10bb9f545acdfb66 ./20/GmailId10bb9ef4f68bfe8f ./21/GmailId10bb8d5a6ca7c3f7 So there are lots of files, taking lots of space, and some of them are from when I first started using evolution (100 days ago, or so). Is this what is supposed to happen? How is the cache supposed to be kept to a reasonable size?
Confirmed on 2.12.1-0ubuntu1. user@ubuntu:~/.evolution/mail$ du -ksh pop 57M pop user@ubuntu:~/.evolution/mail/pop$ find . -type f | wc -l 1730 user@ubuntu:~/.evolution/mail/pop$ find . -type f -mtime 200 | wc -l 425
It will be good if you can try in 2.24 ( planned date of release sept 15, 2008 ) where camel db summary has been introduced and let us know.
Can somebody please retest with 2.24?
(Note to myself: Downstream report: https://bugs.maemo.org/show_bug.cgi?id=3949 ) ~/.evolution/mail/pop/3582480_auth\=CRAM-MD5\@pop.gmx.net/ lists only one file: uid-cache ~/.evolution/mail/pop/3582480\@pop.gmx.net/ lists cache folders.db and cache still includes lots of subfolders (=BUG), but at least they seem to be all empty. Now why do I always have two folders for the same POP accounts?! Evo 2.24.3
You changed the authentication type, so Camel thinks it's a whole new account. It's a design flaw in Camel: it doesn't know about account names, only URIs.
Matthew, that does not explain that both folders seem to be used (see the date): $:andre\> cd .evolution/mail/pop/ $:andre\> ll -s 15955031\@pop.gmx.net/ total 8 4 drwx------ 24 andre andre 4096 9. Feb 00:25 cache 4 -rw-r--r-- 1 andre andre 3072 13. Dez 21:48 folders.db $:andre\> ll -s 15955031_auth\=CRAM-MD5\@pop.gmx.net/ total 0 0 -rw-rw-r-- 1 andre andre 0 9. Feb 13:42 uid-cache
Downstream ticket at https://bugs.maemo.org/show_bug.cgi?id=3949
Andre, your bug is different from the initial, yours is rather bug #445439. The problem is that pop3 emails are copied to On This Computer/Inbox, thus deleting in that folder (or expunging On This Computer/Trash) does not invoke appropriate methods on the pop3 store/folder. (In reply to comment #4) > and cache still includes lots of subfolders (=BUG) It's not a bug, it's intentional. Having cache cleared, probably, is only when there is not checked "Leave messages on the server", in that case they are immediately deleted even from the local pop3 cache. If their respective files are or are not, is the question for this bug report.
I just tried this with actual master, ~2.30.0, and as long as the pop3 provider is removing the message from its cache (for example when not having checked "Leave message on the server"), then the cached message on the disk is also removed. The subfolder not, but as I said, it's correct. Could also anyone else retest with 2.30.0+, please? Thanks in advance.
Hm. I'm closing as OBSOLETE then. Please reopen if this is still an issue.