User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 Build Identifier: version 2.0.0.18 (20081105) When using IMAP and option mail.server.default.autosync_offline_stores is set to true. Compacting of local folders is not working Reproducible: Always Steps to Reproduce: 1.Empty a folder 2.Select the option on this folder to compact 3. Actual Results: Not working, nothing happen. Even the summary compacting is not displayed. Expected Results: the actual size on the hdd must become smaller

Does it make a difference if the folder is selected for off-line use on its properties dialogue?

It does make a difference. If a folder is selected for off line use, the folder does not appear to compact. If the same folder has off line use disabled, the compact does work. Looking at the protocol logs, I emphasize the word "appear". Thunderbird sends an expunge to the server, and the server deletes the message. However, Thunderbird continues to display the folder as if the messages are marked as deleted but not expunged. Quitting Thunderbird and restarting it, or rebuilding the index file, repair the situation. I confirmed this today on the Thunderbird 3, Beta 2 Release Candidate: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090218 Lightning/1.0pre Thunderbird/3.0b2

(In reply to comment #2) > Looking at the protocol logs, I emphasize the word "appear". Thunderbird sends Can you attach the protocol logs to the bug ?

Attached is a protocol log showing Thunderbird's actions when a folder appears not to compact. This log is extracted from just before the message \Delete flag is set until Thunderbird quits, while the folder was marked for offline use.

Saul, are you using the imap delete model, such that deleted messages are shown with a red X in the message list?

Yes, I'm using the imap delete model. (I'm an old purist)

Bug 463359 is report of same symptom for Tb 2.0.0.17. After open of Bug 463359 & this bug(Comment #0 for Tb 2.0.0.18), Bug 420115 & Bug 466730 were fixed. > Bug 420115 : fixed on 2008-11-21, fixed by Tb 3.0b1 > Bug 466730 : fixed on 2009-01-31, fixed by Tb 3.0b2 Comment #2 is report for Tb 3.0b2(problem of same external symptom even after fix of Bug 420115 & Bug 466730). Comment #0 and Comment #2 are really same problem(same cause/same condition)?

I think following action is adequate. > (1) Close this bug(original problem of comment #0) as DUP of Bug 463359. > (2) Open separate bug for comment #2(even after fix of Bug 420115 & Bug 466730) To Saul Tannenbaum(comment poser of comment #2/comment #4). What do you think? See Bug 466730 Comment #26, please. I'm still not sure phenomenon of Bug 466730 Comment #22 is irrelevant to Gmail IMAP. To David Bienvenu: What do you think about difference between your "WORKSFORME" in Bug 466730 Comment #23 and Comment #2/Comment #4 for Tb 3.0b2?

This bug hasn't gone away, but it's behavior over time has changed. 1) It's not a dup of https://bugzilla.mozilla.org/show_bug.cgi?id=463359 because it's not limited to the INBOX, and because the user-visible symptom is mail appearing not to be deleted. That's very different issue to the user than the Thunderbird internal files growing. 2) Comment 2 doesn't seem to be valid any longer. I've seen this on folders that are enabled for offline use, and for folders that aren't. My time to deal with this is limited. My personal plan was to wait for Beta 3, and do what I could then to more carefully characterize this bug, if it still existed. I welcome feedback from the developers on how I could best help them. I think of this, from the user perspective, as a very serious bug, and would like to be maximally useful in stomping it out.

(In reply to comment #9) > 1) It's not a dup of ... 463359. Saul Tannenbaum, which is the "It"? a) Original report of comment #0 for Tb 2.0.0.18 b) Your comment #2 for Thunderbird/3.0b2 c) Your comment #9 for Thunderbird/3.0b? (Comment #2 doesn't seem to be valid any longer) Saul Tannenbaum, can you open separate bug, with detailed description such as "delete model", "offline-use=yes/no", ...? See Bug 466730 #25 & #26, please. See also Bug 487992. I'm still not sure that GMail IMAP is irrelevant to "Tb trunk never decreases size by compact folder" case. So I could open bug for "Tb trunk increases size by rebuild-index" case only. (I'm not developer. Merely a user who can test with Tb latest-trunk.) > Bug 487992 File size of offline store of IMAP folder increases upon each "Rebuild Index"

FYI. Bug 495862 has been opened for "never shrink by compact" for Tb Trunk.

To Gentle(bug opener, for Tb 2.0.0.18): Can you produce problem with latest Tb 2.0.0.21?

Changing Version: from "1.9.1 Branch" to "1.8 Branch", because this bug is report for Tb 2.0.0.18. To Saul Tannenbaum: Please don't hi-jack/morph bug report of similar external symptom but probably for different problem from yours. Phenomenon of "compact of latest Tb trunk doesn't reduce offline-store file size" is being analyzed by Bug 495862 and Bug 499630. Please watch these bugs, if you are still experiencing problem with Tb trunk nightlies. (In reply to comment #0) > Compacting of local folders is not working >(snip) > Expected Results: > the actual size on the hdd must become smaller To Gentle(bug opener): Does your "Compacting of local folders is not working" mean "offline-store file size is not reduced by Compact Folder" only? Or "expunge command is not issued" is also involved? > When using IMAP and option mail.server.default.autosync_offline_stores is set to true. Does it mean no problem occurs if mail.server.default.autosync_offline_stores is ser to false? Which delete model do you use?

To all problem reporters for Tb trunk(next Tb 3): Read Bug 499630 Comment #23, and never add comment relates to Tb trunk(next Tb 3) in this bug any more, please.

Closing this bug as DUP of Bug 463359. Gentle(bug opener), please re-open DUPing is found to be wrong.