Created attachment 258837 [details] mailbox with . saved search Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:18.104.22.168pre) Gecko/20070315 Thunderbird/2.0pre Mnenhy/0.7.5.0 ID:2007031503 You will lose a folder functionality when you create a saved search named as "." as inbox sub folder. The inbox will turn into a saved search. STR: 1. Create a new profile with a pop3 account 2. Create a new Saved Search name "." - - Create this Saved Search on a subfolder as: "Create as a Subfolder of: Inbox on <your account> After you created the saved search, you will see that "." has no saved search icon, it has the inbox icon (see attachment). The original "inbox" in this case has the folder options (compact, etc..), the saved search "." has the Saved Search options (edit saved search properties...) When you restart Thunderbird, both "inboxes" folder have only the saved search options and the original mailbox folder options (compact, etc...) are gone.
Yes, I see this. Not only does the Inbox only provide the saved search options in the context menu: it only shows the search results, you can't see the rest of the messages! The way to fix it is to close TB and delete the Inbox.msf file, so it's not complete dataloss problem, but a nasty little bug.
(In reply to comment #1) > The way to fix it is to close TB and delete the Inbox.msf file, so it's not > complete dataloss problem, but a nasty little bug. I take it back -- this doesn't fix the problem. My Inbox is *still* showing as a Search folder when I click the context menu. With TB 2.0pre-0317, clicking on the folder itself shows no items at all in the thread pane. Still looking for a way to revert.
try removing virtualFolders.dat (or editing it)
Thanks for the tip, but no joy. I renamed virtualFolders.dat and Inbox.msf, and I'm seeing the same results. Immediately after removing Inbox.msf (which is for my primary inbox), on restart, the thread pane shows the expected (non-search) contents. Every subsequent access to the Inbox completely fails to update the thread pane -- it shows whatever previous contents were there. (No errors in console.) And the context menu is a still a search-folder's context menu. Existing search folders that don't look in the Inbox show their expected search results, and on exit, virtualFolders.dat is rebuilt without the bogus entry for Inbox. I still have the original broken virtualFolders.dat, the one after my first restart after deleting Inbox.msf. The lines of interest are: uri=mailbox://nobody@Local%20Folders/_demo/Order2-All scope=mailbox://firstname.lastname@example.org/Inbox terms=OR (subject,contains,dyl) searchOnline=false "Order2-All" is an previously existing search folder, and its contents have here been exchanged with the search that I'd assigned to the "." folder. When I started TB with no virtualFolders.data file, it rebuilt -- Order-2 is still incorrect, but with some other search folder's criteria. I'm getting pretty far afield from the original bug, but I still can't get TB to display my original Inbox correctly, and every time I tweak something, some other search folder breaks.
OK, I just removed all search folders except for two that had nothing to do with the Inbox, removed virtualFolders.dat, removed (again) Inbox.msf. Restarted. The two remaining search folders both operate correctly. Inbox still shows nothing, and its context menu still shows the Search Folder options. Inbox:Properties shows what seems to be an uninitialized search [Subject, contains, <empty>]; if I Choose Folders, no folders are selected and Inbox (obviously) is not presented as one of the items to be searched. And when I exit TB and check virtualFolders.dat, it only has two, correct, entries for the two existing search folders.
all that's left is removing panacea.dat
Thanks -- removing panacea.dat did the trick. The other thing I noticed when I first added the "." search folder: it showed as having all the same subfolders as Inbox had.
If my regular expression foo was strong enough here's what I'd do: Add a regular expression test here: http://mxr.mozilla.org/mozilla/source/mailnews/base/resources/content/virtualFolderProperties.js#208 that replicates the C++ sanity checks we run when creating a new mail folder. In particular: * Any name containing a ; or a # is illegal. * Any name whose first character is a . is illegal * Any name that ends with a . or ~ or a space is illegal If the name fails one of these rules, display the folderCreationFailed string from messenger.properties (http://mxr.mozilla.org/mozilla/source/mail/locales/en-US/chrome/messenger/messenger.properties#88)
Created attachment 259145 [details] [diff] [review] a fix This regexp seems to be doing the right thing for me.
Comment on attachment 259145 [details] [diff] [review] a fix I think we should consider this for the branch tonight...
Fixed branch and trunk. If you are feeling brave tomorrow Tomcat, feel free to test this sucker out :) Here are the rules that should trigger the alert: * Any name containing a ; or a # is illegal. * Any name whose first character is a . is illegal * Any name that ends with a . or ~ or a space is illegal
verified on the 1.8 branch using a Windows version 22.214.171.124 (20070326) build. I tried all combinations in Comment 11, and in each case I was given an alert announcing I could not create a folder with an illegal character.