maildir - local imap folders keep growing
Hi all,
I am running 45.1.1 on Windows 7. I have an imap account using maildir (file-per-message) and storing all messages locally (mirroring the server) to be accessible offline.
Regardless of deleting messages or compacting the folders the local folders continue to grow steadily over time. I don't know if compacting is supposed to work on maildir folders, but it is enabled so I tried it: it routinely claims that it has freed varying amounts of space, but it seems that the message is a lie because the space is never recovered.
Today, my local imap folders were ~6GB when there is only ~1.5GB of mail on the server. I have admin access to the server, so with some effort to identify my messages, I can compare [roughly, modulo filesystem] the space used directly. I deleted Tbird's local imap folders and (re)synchronized with the server, which returned local space used to ~1.5GB as it should be.
Is anyone else seeing a similar problem? Does anyone know what's going on? And should compacting work on maildir folders?
I spent some time looking at bugzilla but I didn't see anything open that seemed relevant. I'm also uncertain how to report this because I don't know what's happening. I checked the obvious offenders - inbox, sent, etc. - which see a lot of churn, but they seem to be in sync with the server. The problem, whatever it is, lies elsewhere (maybe synchronization?) and it is difficult and time consuming to examine my large number of subscribed folders one by one.
Thanks, George
Wszystkie odpowiedzi (2)
Interesting observation. I'm not sure that "compacting" has any relevance to a maildir storage. Each message is a discrete file and deletion of that should, you would think, be a simple deletion job delegated to the OS. Compacting relates to the storage of multiple messages in one file and the need to rewrite that file in order to remove the hidden queued-for-deletion files.
Thunderbird's indexing files are an obvious possible overhead but I wouldn't expect them to be THAT big, and if you remove them they would quickly be regenerated, so you wouldn't have seen the local storage size shrink back to match that on the server.
Hmm, lots of short messages and large minimum file allocation blocks? No, again you wouldn't see it shrink....
Interesting observation. I'm not sure that "compacting" has any relevance to a maildir storage. Each message is a discrete file and deletion of that should, you would think, be a simple deletion job delegated to the OS. Compacting relates to the storage of multiple messages in one file and the need to rewrite that file in order to remove the hidden queued-for-deletion files.
Thunderbird's indexing files are an obvious possible overhead but I wouldn't expect them to be THAT big, and if you remove them they would quickly be regenerated, so you wouldn't have seen the local storage size shrink back to match that on the server.
Hmm, lots of short messages and large minimum file allocation blocks? No, again you wouldn't see it shrink....