On 11/22/2011 5:07 PM, Timo Sirainen wrote:
On 23.11.2011, at 0.25, Stan Hoeppner wrote:
On 11/22/2011 12:30 PM, Timo Sirainen wrote:
On 22.11.2011, at 19.00, Stan Hoeppner wrote:
The current operation on '1-Spam-l' did not succeed. The mail server for account stan@hardwarefreak.com responded: Mailbox doesn't exist: 1-Spam-l .. /$ la /home/stan/mail/1-Spam-l.gz -r-------- 1 stan stan 14M Oct 28 2010 /home/stan/mail/1-Spam-l.gz
The name is now "1-Spam-l.gz", not "1-Spam-l". (Subscription file not updated?)
Aha. That was it. Thanks Timo. For some reason my read of the wiki page made me think this was handled transparently--just zip the file and everything works as it did before. Apparently it's not as simple as the wiki leads one (me anyway) to believe.
I thought about doing something smarter, but then I thought "no one uses compressed mboxes for anything important anyway" :)
Out of curiosity, what (or who) prompted the development of the compressed mbox feature? Or was it that you wanted to do it for maildir, and then figured you should for mbox as well? The implementation seems to work ok. The instructions just seem a bit...thin. :)
This bit of the wiki caused me some confusion as well: "Compressed mbox files can be accessed only as read-only"
Thus I chmod'ed the .gz file to read-only. This creates a problem. It appears that when Dovecot creates the .imap folder of the same name it inherits the permissions of the zipped mbox file. Thus it can't create the indexes:
I've fixed this in some version. I guess in v2.0.
Yeah, I'm waiting for Debian to get a backport of 2.0.x. For many reasons the only thing I'm comfortable installing from source is the Linux kernel.
Reverting with 'chmod +w' fixed this. Maybe that sentence in the wiki could be reworded in a way that doesn't prompt some folks to manually make the zipped files read-only.
Well, I don't really care that much about v1.x anymore.
Understandable.
It took a while for Dovecot to index the 15K+ messages. With that finished, accessing the folder is similar to before, but there's a small lag when opening messages.
Yeah, it's uncompressing the entire file until it finds the message you're opening.
It's pretty damn fast at it. I haven't seen anything more than a couple of seconds lag while randomly accessing mail all over the folder. The original gzip of the file took >45 seconds.
As this is an archive folder the contents won't change, so Squat FTS should be very fast after the first search, just as before. Interestingly, it appears my squat indexes aren't updating--for any folder. I've searched 4 folders via Tbird body search with xyzzyx (took forever) and I see no changes to the dates or sizes of existing indexes. I deleted the squat indexes for one folder and ran the search again. No new squat indexes were created. No errors in the logs.
Any ideas why the squat indexes aren't updating? IIRC this happened once before and I was able to fix it. Don't recall how I did it though....
mail_plugins: zlib
Doesn't look like fts, fts_squat is enabled?
Stupid me. When I enabled zlib I created a 2nd mail_plugins line. So 'mail_plugins fts fts_squat' got ignored. Didn't realize all plugins had to be declared in a single line directive. I did this as part of my troubleshooting when zlib wasn't working, thinking putting it on it's own line may help--not.
-- Stan