[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070131 SeaMonkey/1.5a] (nightly) (W2Ksp4) A case of: "Compact This Folder" is updating (one of) my IMAP Inbox.msf, but is not shrinking my Inbox file, not even touching it (= size & date don't change).

Current case: 0a. Deleted all messages in that Inbox. 0b. Stopped SeaMonkey. 0c. Deleted both files. 1. Start SM/MailNews. 2. Wait until a new message arrives. 3a. Delete it. 3b. Compact Folder. At step 3b, only the .msf files is updated at all. The data file is keft untouched. Restarting SM and retrying Compact does not help.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7] (release) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.2pre) Gecko/20070123 SeaMonkey/1.1] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070131 SeaMonkey/1.5a] (nightly) (W2Ksp4) As in bug 344644 comment 1, (stopping SM and) deleting / rebuilding the .msf file does not help either.

[Mozilla Thunderbird, version 3 alpha 1 (20070202)] (nightly) (W2Ksp4) Same bug in Thunderbird, tested by sending a message to myself.

Hmm, why do you have a data file on imap? Is it marked as offline? (I don't seem to have any, just the .msf.)

(It seems I missed your comment.) Yes, I enabled "Make the messages in my Inbox available when i am working offline". [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4) Bug still there: I deleted a 130 MB file, which was recreated as a 3.3 MB one. [Mozilla Thunderbird, version 3.0a1pre (2008021003)] (nightly) (W2Ksp4) Bug still there: I deleted a 4.7 MB file, which was recreated as a 3.3 MB one.

Regression of Bug 222938 ?

(In reply to comment #6) > Regression of Bug 222938 ? Yes, it would seem that this bug enabled this feature at that time; then, the current bug would be a regression which occurred in the meantime. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414] (release) (W2Ksp4) Bug already there.

(In reply to comment #6) > Regression of Bug 222938 ? Thanks again ! The (old code in the) patch there gave me a hint: (In reply to comment #4) > Is it marked as offline? (In reply to comment #5) > Yes, I enabled "Make the messages in my Inbox available when i am working > offline". Actually, I do have this option enabled; but the folder itself is not marked with "Select folder for offline use" option. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4) I tried being offline, but that didn't work, as expected. Then, I enabled the folder itself for offline use, then I could compact a 17 MB file, which was reduced to a 4 MB one; and the .msf from 102 KB to 68 KB :-) *** Suggestions: Backend way to solve this: <http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/imap/src/nsImapMailFolder.cpp&rev=1.798&mark=1164,1167#1163> should check for the Inbox pref too. UI way to solve this: (un)Setting the Inbox pref should automatically (un)set the Inbox folder for offline use; and vice-versa. (Or maybe get rid of that Inbox pref ??)

Weird. I just examined my IMAP accounts and found one that had "Make the messages in my Inbox available when i am working offline" checked, but "Select this folder for offline use" in the Inbox folder properties unchecked, just like yours - the size of the INBOX file is nearly 90MB with an actual Inbox size of only 5MB, while all other INBOXes are behaving normally. Apparently there are two preferences for the same thing (first mail.server.xxx.download_bodies_on_get_new_mail, and second MSG_FOLDER_FLAG_OFFLINE of the INBOX folder) that can be set to contradicting values, giving unexpected results. I was not aware either that unchecking "Select this folder for offline use" on the Inbox does *not at all* disable the download of messages, but on the contrary disables the *removal* of messages from the INBOX file when they no longer exist on the server. IMHO that's not just an "enhancement" bug, but a major one, since it does not only cause an enormous waste of disk space, but may also have an impact on privacy/security. After all it means that messages end up in a plain file on your local hard disk that you expected to be on the password protected server only.

There's some UX stuff to resolve here. Assigning to bryan for now. Changing the subject to better reflect the underlying cause as I understand it. Marking blocking-tb3+ because it doesn't seem that messy so far!

wow, so confusing! :) Here's what I think our path forward is. In TB3 we'll be defaulting to downloading all mail for offline use. The "Items for Offline Use" dialog (likely needs some work) can be used to create exceptions of which folders to keep for offline; as all folders default to offline. The current checkbox for "Make the messages in my Inbox available for when I am working offline" is redundant and needs to be removed. And the behavior preference below it, we can handle this issue in better ways. If an account isn't selected for offline use, then we don't default to creating folders marked for offline. If an account is selected for offline use then a person who wants to create an offline folder will have to open up the account settings to this page to make the change (or the folder properties dialog). The use case that a person who wants offline access to their mail wants to create a new folder (or folders) not offline doesn't make sense, especially as a pref they would have to turn on or off. So this section should instead look something like this: *Offline* Messages can be downloaded locally so that you can use them while offline. If messages are not offline a network connection will be required to use them. (o) Download messages for offline ( Change folders available for offline... ) ( ) Do not keep messages available offline, download each time

Setting P2 priority and b2 Target

Changed my mind on this one, see bug 436615 comment 14 and the IMAP wiki page https://wiki.mozilla.org/MailNews:Better_Faster_IMAP_Plan#UX_Decisions_to_make

moving to b2

I believe this has been fixed in the account preferences Syncing & Offline section. The folder properties dialog relates to the adv. section of this preference for selecting a folder for offline. So this is fixed now, correct?

looking again... the UI for this has changed to remove the separate INBOX option; so this has been fixed.

The fix happened for SM and TB in bug 436615 comment 93: http://hg.mozilla.org/comm-central/rev/5ad568b3a57b V.Fixed Yet, I wonder if the old preference was kept on backend on purpose: David ? http://mxr.mozilla.org/comm-central/search?string=download_bodies_on_get_new_ma&case=on http://mxr.mozilla.org/comm-central/search?string=DownloadBodiesOnGetNewMail&find=%2Fmailnews%2Fimap%2F

(In reply to comment #15) > I believe this has been fixed in the account preferences Syncing & Offline > section. Actually, my comment 17 is about this part only. > The folder properties dialog relates to the adv. section of this preference for > selecting a folder for offline. That part is still a confusing, I would say: For example, selecting an Imap Inbox in its folder property does not select the "Keep messages ..." checkbox in its corresponding settings, thus its advanced button remains disabled. Which one should I believe ? :-/ > So this is fixed now, correct? Well, shall we reopen this bug for the latter issue ?