398523 - Manual compact folder starts immediately after delete message. Should schedule it with some delay.

Status: RESOLVED DUPLICATE of bug 439089

(MailNews Core :: Backend, enhancement)

Description

[Diego Ballve]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070805 Firefox/2.0.0.6
Build Identifier: 2.0.0.6

Compact folder is a good feature to save space on todays' overspammed inboxes. But when the folder starts getting big, compacting it is a slow process.

A fair price to pay, acceptable if user is not trying to do something with inbox, but generally when you are deleting messages you might delete more than 1 message sequentially. That is when the problem hits in: if thunderbird notices it could save more than configured threshold, compact folder jumps in immediately and user is left waiting to delete the next message/spam.

My suggestion is to schedule a delayed compact folder action instead of triggering it. Give user a couple of minutes, then start compacting.

Reproducible: Always

Steps to Reproduce:
1. Choose a folder w/ tons of messages
2. set compact folder trigger for a very small size, say 50kb
3. delete a few messages
Actual Results:  
you have to wait for compacting to end before deleting a few more

Expected Results:  
mmm.. ok, I could save some space if I compact this folder now... I'll start compact folder in 5 minutes if no more messages are deleted..

Comment 1

[Paul Boserup]

I agree this is most frustrating. I occurs every time I process new messages.
Compacting should be a background process which does not interfere with using the applpication. -pb

Comment 2

[bkaplan]

I concur on this one. Any chance of someone putting a setting in which would wait until the UI is idle for X period of time prior to compacting?

Comment 3

[Wayne Mery (:wsmwk)]

this should be solved by bug 439089

Comment 4

[rsx11m]

I don't see this bug here referring to IMAP, but bug 439089 seems to be targeting this as a whole with IMAP being the motivation for solving it. Nevertheless, if this bug is a duplicate it can't be a dependent bug.

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> I don't see this bug here referring to IMAP, but bug 439089 seems to be
> targeting this as a whole with IMAP being the motivation for solving it.

I didn't reread the entire bug, but despite the summary my recollection is that pop3 is also part of the bug (after all, compact is not unique to imap). OTOH, perhaps there are more appropriate bugs to dup to, like 286888 or bug 324576.

> Nevertheless, if this bug is a duplicate it can't be a dependent bug.

using blocking to trigger future bugmail, so that when the blocker bug is fixed, someone is reminded to check that this bug, the dependent issue, was in fact also fixed. (the alternative is to leave this bug open, which doesn't make much sense to me)

Comment 6

[rsx11m]

I see, it wasn't clear to me if you set the dependency by accident or on purpose. I'd usually indeed leave the bug open in such cases and let it depend on the bug which is supposed to fix it, then resolve either WFM or FIXED [by bug xxx] in the whiteboard once it's verified that the issue in the dependent bug was fixed. If it's exactly a duplicate I'd dupe it without dependency.

It seems to me that the backend for compacting is the same at this time for offline copies and "regular" local folders, thus it should be fixed in the same effort. However, bienvenu probably knows best.