User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:184.108.40.206) Gecko/20061204 Firefox/220.127.116.11 Build Identifier: Version 2 beta 2 (20070210) Renaming a folder by way of rightclick->rename, causes the folder properties to be lost after the name is changed. However, if selecting rightclick->properties, and changing the name there, the folder retains it's properties. Reproducible: Always Steps to Reproduce: 1.right-click on a folder, select 'properties', then click "check this folder for new messages" 2.right-click on the same folder, select 'rename' 3.rename the folder 4.go back into the properties for the folder, it has lost it's checkbox for "check this folder for new messages" Actual Results: Folder properties are lost Expected Results: 1) Expect the folder to retain it properties after rightclick->rename 2) Expect the behavior of rightclick->properties->name change to be the same as rightlick->rename
->NEW on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168pre) Gecko/20070212 Thunderbird/2.0pre ID:2007021203 I tested on IMAP.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: Macintosh → All
Version: unspecified → 2.0
One of causes of property loss is garbage of ".msf" file for old saved search folder(virtual folder) under IMAP account. Following is test result with an IMAP account/Tb latest trunk. (1) Create virtual folder of "A", and open "A" => A.msf, A.sbd is created (A.sbd is another bug) (2) Rename "A" to "B", and open "B" => B.msf, B.sbd is created. A.msf,A.sbd is not deleted. Property is good. (3) Rename "B" to "C", and open "C" => C.msf, C.sbd is created. A.msf,A.sbd,B.msf,B.sbd is not deleted Property is good. (4) Rename "C" to "A" => A.msf is re-used. File size of A.msf becomes 0. Property is lost => Redefine search rule (5) Rename "A" to "B" => B.msf is re-used. File size of B.msf becomes 0. Property is lost => Redefine search rule (6) Rename "B" to "C" => C.msf is re-used. File size of C.msf becomes 0. Property is lost => Redefine search rule Main cause of above is that Tb doesn't delete old file(and directory) upon rename. This is IMAP account unique issue. Workaround: (a) Define search folder under (dummy) POP3 account or "Local Folders". (b) Use delete/define instead of rename. (no garbage when delete)
Correction. Above was test result with Tb 22.214.171.124. With Tb latest trunk, phenomenon was different. (1) Create virtual folder of "A", and open "A" (IMAP account) => A.msf is not created at expected location. > virtualFolders.dat > uri=imap://Y-One@imap-gmail.mail.server/Label-A/AB > A.msf was created at (A.sbd was not created) : > %APPDATA%\Thunderbird\Profiles\<profdir_name>\ImapMail\AB.msf > Expected location (where virtualFolders.dat points to) : > %APPDATA%\Thunderbird\Profiles\<profdir_name>\ImapMail\<server_name>\Label-A.sbd\AB.msf (2) (2a) If renamed, property is lost. (2b) If restarted, property is lost too. (2b) is probably already reported bug.
With Tb 126.96.36.199, even if garbage of X.msf(and X.sbd) of old name remains under IMAP account, the X.msf file is deleted upon first server connection after restart(or Subscribe window open), because folder of X doesn't exists at server. So garbage(not deleted by Tb 2) is usually X.sbd directory only. To Robert Thompson(bug opener): Is the Virtaul folder(Saved search folder) defined under IMAP account? Or under POP3 account or "Local Folders"? Did you rename multliple times in single Thunderbird session? (1) Rename A => B => C By the way, I opened Bug 450059 for issue of comment #3 on Tb Trunk.
Whiteboard: [closeme 2011-03-21][dupeme]
(In reply to comment #5) > wada, so only 2a of comment 3 is in question? No. If conditions of comment #3 exist, the "2a" occurs. Please note that comment #0 by bug opener is read "problem occurs upon any rename of virtual folder". But I could observe problem only when; Rename just after creation, or, multiple rename in single Tb session. I can say nothing about original pheomenon of this bug.
RESOLVED INCOMPLETE due to lack of response to previous question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.