User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 It is reasonable to zero the filesize of Inbox if Inbox is empty. Mail check utilities rely on this to flag mail folder status. Reproducible: Always Steps to Reproduce: 1. Receive some mails 2. Delete all of them. 3. Check the 'Inbox' file in mozilla Mail directory. It is not empty. Actual Results: The file size of Inbox is not zero. Expected Results: The file size of Inbox should be zero.
one caveat - if we ever undo shift delete of local messages, we would not want to compact empty folders immediately, because that would prevent us from undoing that shift delete.
Assignee: bienvenu → naving
Status: UNCONFIRMED → NEW
Component: Mail Database → Mail Back End
Ever confirmed: true
Assignee: naving → sspitzer
I agree on the suggestion to zero the inbox filesize, at least when the inbox folder is emptied by the spam filter.
Is this about local inbox?
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: esther → backend
Product: Core → MailNews Core
This report is essentially a duplicate of another: https://bugzilla.mozilla.org/show_bug.cgi?id=286888#c57 Both suggest to compact automatically. Both - not required. Both already implemented: there's a preference to allow automatic compaction. It works not only on Inbox, but on all folders. A suggestion to compact after an action by spam filter is not good too. Because the filter occasionally removes good messages. It is not a big difference whether you remove something by hand, or by filter. Both are accidents. Both need to be guarded against. You suggest to help the accident propagate, and evolve.
I think this bug, strictly speaking, is a subset of bug 286888. But maybe Bienvenu or others think otherwise. As for bug 286888, is not yet implemented. Yes, automatic compact is now the default. But that doesn't go far enough. The idea behind bug 286888 is to increase the level of "smartness" of automating compact, that absolutely no UI is needed, including preferences. So for example, it should be adaptive so that it is performant for widely varying folder sizes and message sizes. Currently it does not do that.
My point is different: automating compact takes away control from the user. One may not want to compact at all for many reasons. Some are mentioned in the duplicate bug. The default should be not to compact automatically. Nothing should be lost without knowledge of user. The point about "smartness" is pointless. A compact is still a compact regardless of folder size, or apparent emptyness. I do not see any essential difference between a non compacted folder with 1 message, and the same with no messages. A person may still not want to compact. If you think it is a duplicate, then close it. No need to keep many open bugs.
it is not a duplicate
You need to log in before you can comment on or make changes to this bug.