should compact Inbox automatically if it is empty.



17 years ago
7 years ago


(Reporter: cp76, Unassigned)


(Depends on: 1 bug)


Firefox Tracking Flags

(Not tracked)




17 years ago
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.


17 years ago
Severity: normal → enhancement

Comment 1

17 years ago
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
Component: Mail Database → Mail Back End
Ever confirmed: true


17 years ago
QA Contact: gayatri → esther
mass re-assign.
Assignee: naving → sspitzer

Comment 3

15 years ago
I agree on the suggestion to zero the inbox filesize, at least when the inbox
folder is emptied by the spam filter.
Product: MailNews → Core

Comment 4

13 years ago
related to bug 61960
Depends on: 61960
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


11 years ago
Product: Core → MailNews Core

Comment 8

7 years ago
This report is essentially a duplicate of another:

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.

Comment 10

7 years ago
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.