1) use the default all accounts folder view. 2) Create a local folder. Mark it as a Favorite Folder. 3) Rename the folder. Note that the favorite folder status has been preserved. 4) Rename the folder again. 5) Note that the favorite folder status has been lost.

Hmm, this problem isn't limited to favorite folders. Renaming a saved search folder twice causes us to lose the saved search flag too.

When renaming a folder for the second time, the flags we extract from nsDBFolderInfo are 0. the first time we rename it, we create a new folder info object and we open up the newly copied .msf file. http://lxr.mozilla.org/seamonkey/source/mailnews/db/msgdb/src/nsDBFolderInfo.cpp#417 nsDBFolderInfo::LoadMemberVariables reads the correct flags out of the new .msf file. The next time we rename it though, we get 0 here instead of the actual flags. Not sure why yet.

I just did an interesting experiment that might make sense to David involving the folder cache. 1) Create a new empty local folder and mark it as as a favorite. Restart the app and verify it is still marked as a favorite. 2) Rename the folder. Quit the app. Notice that the .msf file is smaller disk size wise than the orginal .msf file. I would have expected them to be awfully close if not identical in size. 3) Remove panacea.dat and restart. 4) Notice that the favorite folder status on the renamed folder has been lost. So I think even with the first folder rename operation, we are getting into trouble, the folder cache is preventing us from noticing that the flags in the summary file are no longer correct.

yes, the folder cache might be involved. I can look at this tomorrow.

Linux too. The saved searches case is bug 320118.

verified on the 1.8 branch using the Tbird cand build, version 2.0.0.0 (20070326). I tested using Win Vista. I checked renaming both virtual folders and favorite folders, with favorable results. Adding branch verified keyword.