177074 - should compact Inbox automatically if it is empty.

Status: NEW

(MailNews Core :: Backend, enhancement)

Description

[Edward Liu]

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.

Comment 1

[David :Bienvenu]

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.

Comment 2

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 3

[Hans Schleichert]

I agree on the suggestion to zero the inbox filesize, at least when the inbox
folder is emptied by the spam filter.

Comment 4

[Jo Hermans]

related to bug 61960

Comment 5

[Wayne Mery (:wsmwk)]

Is this about local inbox?

Comment 6

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 7

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 8

[Andrew]

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

[Wayne Mery (:wsmwk)]

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

[Andrew]

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

[Wayne Mery (:wsmwk)]

it is not a duplicate