linux thunderbird 2005-09-02-07-trunk, also branch STR, reproducible 5/5: 1. Create a folder on an IMAP account 2. Delete the folder 3. Empty Trash on the account 4. Restart Thunderbird Expected: No sign of deleted folder in UI or on disk Actual: Deleted folder shown both in original place and under Trash on every startup; disappears after a few seconds, presumably as the server is reached and it turns out they don't exist. A .msf file corresponding to the folder is in the profile both in the original location and under Trash.sbd. No mbox files. Happens whether the new folders is selected for offline or not.
I can confirm this on Windows XP Thunderbird 20051017
Confirmed on Thunderbird 1.5 RC1 (not sure if that is the same as 20051017).
*** Bug 329589 has been marked as a duplicate of this bug. ***
Can confirm this one on TB 1.5 (en_US and DE) on XP SP2.
I can confirm this under Windows XP SP2 (US English) with Thunderbird 1.5, including finding the .msf files in 2 places as specified in the original report (except instead of the subdirectory Trash.sbd, I have "Deleted Items.sbd" for compatibility with Microsoft Outhouse). I also found that once in a blue moon, ghost folders actually will go away permanently, and their .msf files will disappear; however, the last time this happened was probably under a Thunderbird 1.5 Beta version (or maybe even Thunderbird 1.0.something). I was able to confirm the bug just now because months (or maybe several versions) can go by between deleting a folder and having the ghost disappear. Possibly related .msf file weirdness: I also noticed that I have a couple of other weird .msf files. One of these is Drafts-1.msf (does not correspond to a folder I ever had or deleted, but maybe it corresponds to Drafts without the -1, because I don't have a Drafts.msf except under the directory for local mail folders). The other is a pair of files corresponding to my "Sent Items" mail folder (one is "Sent Items.msf" and the other is "Sent%20Items.msf", which is much shorter than the first, but both get their "Date Modified" updated frequently).
I see the same behavior on latest trunk build on Win 98. The problem appears to be *.msf never are deleted properly. I can go through a similar sequence to what's given above and eventually (lots of CPU churn) the Folder pane in Thunderbird will correct itself to show only *real* Folders on my IMAP server and the *.msf files never get deleted. Exiting and restarting creates the same CPU churn. I've tried resyncing followed by File->Close and File->Exit. It appears the first fix is to correctly remove *.msf files when Folders disappear or a resync is done. The only way I can fix this is to delete or rename the IMapMail directory under my profile, create an empty directory, then restart Thunderbird.
You could alternatively delete just the offending .msf files. Bug also applies to SeaMonkey 1.0.1 under Windows XP. Attempted to change OS to All, but only reporter/assignee/etc. can do that. (Why? In this case, the reporter is not on the Cc list, and the assignee is nobody...)
Have you tried TB 2.0 beta 2?
No, not yet. Is it possible to install it parallel to 22.214.171.124?
Yes, it is. You might want to back up your profile first, because 2.0 changes filters and saved searches that involve labels, but if you don't have any of those, you should be fine. I run both all the time.
(In reply to comment #9) > Have you tried TB 2.0 beta 2? I can confirm that here an *.msf is left in profile with Th 126.96.36.199 but NOT with 2.0 b2
ok, thx, duping.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 316929
Is it possible to install 2.0 and point it to a completely different system and profile directory? Then I could test it without any risk...
you can create a new profile with 1.5.0.x (or 2.0) and just use 2.0 with that new profile. 2.0 might still much with system settings, etc. But as I said, I don't have a problem going between different versions.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.