Open
Bug 177074
Opened 22 years ago
Updated 2 years ago
should compact Inbox automatically if it is empty.
Categories
(MailNews Core :: Backend, enhancement)
Tracking
(Not tracked)
NEW
People
(Reporter: cp76, Unassigned)
References
(Depends on 1 open bug)
Details
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.
Updated•22 years ago
|
Severity: normal → enhancement
Comment 1•22 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
Status: UNCONFIRMED → NEW
Component: Mail Database → Mail Back End
Ever confirmed: true
Comment 3•20 years ago
|
||
I agree on the suggestion to zero the inbox filesize, at least when the inbox
folder is emptied by the spam filter.
Updated•20 years ago
|
Product: MailNews → Core
Comment 5•19 years ago
|
||
Is this about local inbox?
Comment 6•17 years ago
|
||
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
Assignee | ||
Updated•16 years ago
|
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.
Comment 9•12 years ago
|
||
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•12 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.
Comment 11•12 years ago
|
||
it is not a duplicate
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•