User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12 Build Identifier: Hello, Like there is an optional folder based auto delete policy, we could have an optional folder based auto compact policy. Reproducible: Always Steps to Reproduce: 1. 2. 3.

bienvenu, can you envision a scenario where we'd ever want to get this find grained about compaction? (I can't)

Hello, In case of a large amount of spam, the spam folder is going huge. As a workaround of bug #209501 I noticed that compacting the folders decrease the occurrence of this bug. Thus allowing an automatic compacting of the spam folder will temporary fix the issue I encounter.

(In reply to comment #1) > bienvenu, can you envision a scenario where we'd ever want to get this find > grained about compaction? (I can't) Wayne, this would be fine for an extension, but for core Thunderbird I'd rather spend the effort moving to a storage system that didn't require compaction.

(In reply to comment #3) > (In reply to comment #1) > > bienvenu, can you envision a scenario where we'd ever want to get this find > > grained about compaction? (I can't) > > Wayne, this would be fine for an extension, but for core Thunderbird I'd > rather spend the effort moving to a storage system that didn't require > compaction. David shall we duplicate compact issue to the implement maildir bug ?

(In reply to comment #4) > David shall we duplicate compact issue to the implement maildir bug ? Duping any compact issues to maildir doesn't feel right to me. For one thing, it's an entirely different storage architecture from mbox and we don't know yet if everyone is going to want to adopt it, nor when, or how long mbox will live after maildir achieves widespread adoption. IOW, compact issues should probably stand or fall on their own merit and importance, within the context of people who are using mbox.

We're not getting rid of support for mbox in the medium term but it will be less important going forward.