356345 - Junk folder file size does not resize after deleting messages from it.

Status: RESOLVED INVALID

(Thunderbird :: General, defect)

Description

[Alexander Schneider]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

In the Finder, i look up the file size of the junk folder in Local Folders to be 345 MB. In Thunderbird i delete all files from the Junk folder. I quit and restart Thunderbird. The file size remains unchanged.

Reproducible: Didn't try

Steps to Reproduce:
1. Accumulate junk mail in the junk folder in local folders.
2. Delete messages in that folder.
3. Compare file size before and after.

Actual Results:  
File size as shown in my Thunderbird profile remains the same at 345 MB.

Expected Results:  
Much reduced file size.

Comment 1

[Hiro]

I think that the size of the file becomes small if File --> Compact Folders is executed. 

INVALID?

Comment 2

[Hiro]

There are bug286888 and bug205756 if it wants to execute "compact folder" by the automatic operation.

Comment 3

[Alexander Schneider]

Why compacting? The folder contains no messages, and still is 345 MB large. When the number of messages it contains varies, its file size should vary as well, or not? By the way i make the same observation after deleting attachements (via right-click: "Delete all") from messages in a local folder. I do this of course with the intention to rid the computer of files/used space that is redundant. However the file size of that folder remains the same.

Comment 4

[ian]

i can confirm this behavior for ALL my folders in thunderbird version 1.5.0.10 (20070316).

for an account that i don't use often, i completely deleted all my messages from all my folders.  then i deleted everything from the trash folder.  yet somehow, the inbox and trash folders on disk (after closing thunderbird) are 26MB and STILL CONTAIN EVERY MESSAGE I EVER RECEIVED.  

this is obviously some strange usage of the word "delete" that I wasn't previously aware of.

Comment 5

[flamandier]

i can  also confirm this behavior for version 2.0.0.4 (20070604).
I'm running Windoxs XP , not Macintosh .

I deleted all in my "Sent" and "Junk" messages from the thunderbird menu.
There's no message appearing in these folders when I run thunderbird.

However; when i check really folder on the disk , they are still FULL: 750 meg and 232 meg !

so it means nothing was really  deleted. what to do ?

 

Comment 6

[flamandier]

Ok.. compacting is the solution.....

I compacted my folders and everything is fine.

Compacting means "deleting really already deleted files".... good to know

Comment 7

[WADA:World Anti-bad-Duping Agency]

Next MozillaZine Knowledge Base article may help you.
http://kb.mozillazine.org/Compacting_folders

Comment 8

[ian]

i would never have guessed this in a million years... "compacting" sounds too much like "compressing", which suggests to me that my folders will be gzipped and take longer to access. 

is there any way to make the deletion process more streamlined (even more so than what they mention in the article)?  it seems stupid that to delete a message i have to:
 1. delete the message (moves it to the trash)
 2. empty the trash
 3. compact the folders

the simplest way that i can think of to do this would be to explain compacting in the preferences dialog, where it says: "compact folders when it will save over ____ kb".  i specifically remember not checking this box because i thought it meant compression.  

i would say something like this in the preferences: "to run more efficiently, thunderbird can remove deleted messages from the disk in bulk instead of individually."

then below that, the checkbox would be a radio button with these options:
 "delete individual messages from disk immediately" 
 "bulk delete messages every ____ kb"

Comment 9

[Joey Minta]

Given that compacting solved the problem, I'm resolving this as Invalid.  I fully realize that the behavior here isn't very intuitive, and that better labels or automatic compacting could help, but the bug, as described here, simply isn't a bug.  See for instance bug 236922 and bug 286888.