297298 - deleting contents of a folder does not reduce the size of the file on the computer

Status: RESOLVED DUPLICATE of bug 183837

(Thunderbird :: General, defect)

Description

[John Forrest]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4



This happens with all folders with the possible exception of Trash.  If this
keeps up I'll start eating through my HD in no time.

Reproducible: Always

Steps to Reproduce:
Example:
1.  Delete contents of Junk folder
2.  Empty trash

Actual Results:  
Go to profile and look at size of Junk
With no emails located in Junk, the file size is still large (in my case 385MB)

Expected Results:  
I would expect to have seen the size of the file reduced to pretty much nothing
since the folder has no content

Comment 1

[John Forrest]

Oops, forgot to mention that I am using Mozilla Thunderbird 1.0.2

Comment 2

[Steve England [:stevee]]

afair you have to choose to compact your mailbox for this to work. Otherwise TB
would have to automagically compact the mailbox after each deletion, which would
takes ages.

Comment 3

[John Forrest]

I don't think it is unreasonable for one to expect the email to be delete if
they opted to delete it.  To say that you have to jump through hoops A, B, and C
to make sure that you don't run out of HD space over time is just not the way it
should work.  Instead, if a user delete the email, the email should be deleted.
 The user should never have to think about it again.  From what I can tell,
whether I delete emails or not it doesn't matter, the space is forever taken up
unless I wish to jump through some hoops to resolve it, but only until it
happens again.

Comment 4

[ismail yenigul]

The same prolem exist also on INBOX. 
I think if I delete the mail it should be deleted from inbox file.
Why do we have to compact the folder? What it means?

Best Regards

Comment 5

[Matjaz]

TB 1.5 will have an option to automatically compact folders if this saves a
certain amount of disk space.

Comment 6

[jwq]

This bug is similar to Bug 297939, which has been marked as a duplicate of Bug 207736. Recommend the same for this bug.

Reporter (John): Please read Bug 297939 and Bug 207736, and mark this bug as a duplicate of 207736 if you agree that it is a duplicate.

Comment 7

[jwq]

Actually, the most appropriate bug for this to be duped against is Bug 183837 (check its list of 14 duplicate bugs).

Comment 8

[John Forrest]

Well, I have to ask though.  Is this actually resolved or is this a situation where the solution is "it is not my problem, do it yourself."  If the problem is resolved as comment 5 suggests in 1.5 (though I can't use that due to some other bug) then I can live with that and resolve the issue.  Now, if the user has to constantly maintain this and keep compacting manually... then I can't see where the problem is resolved.  Instead, I would say it is just brushed off and ignored.  

If anyone can verify that this is resolved in 1.5 then I would be more than happy to close the bug.  However, I don't want to close the bug if it is just because no one wants to actually address the issue.

As a side note, it probably is a dupe of all these bugs, but I still don't view it as resolved just because the user has to do this manually otherwise they'll fill up their hard drives.  This is particularly true for non-techies.

I hope I at least made some sense...

Comment 9

[Dão Gottwald [:dao]]

This is not resolved in 1.5. But I think it will be resolved when using SQLite, right?

Comment 10

[jwq]

Resolving duplicate, per Comment #7 and Comment #8.

The auto-compact option referred to in Comment #5 is present in 1.5 (Preferences -> Advanced -> Offline & Disk Space). As compacting is a slow process, particularly for large mbox files, compacting after each delete would lead to slow performance.

*** This bug has been marked as a duplicate of 183837 ***