User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031211 Firebird/0.7+ Build Identifier: Thunderbird 0.5a (20040105) A subfolder created under Inbox or Sent folders can be renamed to a longer name but if the name is then shortened, the folder name is not changed as expected while the Windows mail file names (folder & folder.msf) are changed to the expected name. Reproducible: Always Steps to Reproduce: 1. create a folder in Inbox (or subfolder in Sent) and name it 2003. Move mail to this folder. You now have mail file 2003 with its 2003.msf file. 2. rename the folder 2003x. files are now 2003x & 2003x.msf 3. rename folder to 2003. files will be 2003 & 2003.msf, but folder remains 2003x. The only way out of this is to create a new folder, say 200, moves all mail from 2003x to it, delete 2003x and rename 200 to 2003. Actual Results: Folder name is not modified as requested, and its name is not the same as its mail files. Expected Results: Folder name should keep in sync with the file names, and follow the rename command eauirement. Creating a new profile does not solve this problem, the offending name remains.

*** This bug has been marked as a duplicate of 209022 ***

I looked over a dozen folder rename bugs and although this one is marked as a dupe, it most closely reflects what I've observed. In addition, I don't see how bug 209022 (that this bug supposedly is a dupe of) addresses this issue, unless it is as a side effect of the fix created for bug 209022, in which case the person who verified bug 209022 needs to include this bug as a test case (and perhaps this bug should have been listed as being dependent on 209022 instead of as a dupe). Not to mention that the bug still exists in recent Thunderbird releases, even though bug 209022 was apparently fixed a year ago. In any case, using Thunderbird version 1.0 (20041206) I observed something that fit the description above - I was renaming a local subfolder from a name like "05-01-23" to "junk" and observed that the folder position in the tree moved, as if the rename had occurred, but the name listed in the folder tree didn't change. Checking the disk shows that the folder/directory/.msf file all were renamed to junk.* as expected. A notable difference to what the original reporter described is that the problem isn't always reproducible. I renamed 6 folders in a similar way and the problem occurred only 2 times. I'm curious to know where the original folder name is being cached. I noticed the original folder name appeared in the renamed junk.msf, but exiting Thunderbird, changing this to "junk", and restarting Thunderbird didn't change anything. The only work around I've found so far is to delete the *.sbd folder and *.msf file, which of course means loosing message attributes. I also observed that attempting to rename the uncooperative folder again results in the message listing going blank upon clicking OK, but doesn't dismiss the dialog. Hitting cancel will dismiss the dialog, and navigating away and back to the folder restores the listing of messages.

Did another series of tests, which show that handling folder names is still buggy, losing synch after some renaming. .sbd folders do not follow the movement. RESOLVED DUPLICATE is definitely not pertinent. Trouble started in step 3, when name change is not reflected in TB, but does in Windows. Trouble became severe in steps 6 & 7. 1. Created sub-folder 2005 under Inbox. Window files created: 2005, 2005.msf Folder created: 2005.sbd 2. Renamed sub-folder 2005 to 2005x. Folder name changed to 2005x. Window files 2005 & 2005.msf became 2005x & 2005x.msf; Folder created: 2005x.sbd - folder 2005.sbd remained. Files in sync, but folder 2005.sbd should not be there 3. Renamed sub-folder 2005x to 2005y. Folder name did not change. Windows files 2005x & 2005x.msf became 2005y & 2005y.msf. Folder created: 2005y.sbd Now 2005.sbd, 2005x.sbd, 2005y.sbd are present and will remain forever 4. Renamed sub-folder 2005x to 2005. Folder name changed to 2005. Window files became 2005 & 2005.msf. 5. Renamed sub-folder 2005 to 2005x. Folder name changed to 2005x. Windows files became 2005x & 2005x.msf 6. Renamed sub-folder 2005x to 2005y. Folder name changed to 2005y but data disappears. 7. Closed & reopened TB: both sub-folders 2005x & 2005y are present Data is in sub-folder 2005x, sub-folder 2005y is empty. Windows files are 2005y &2005y.msf

(In reply to comment #3) > Did another series of tests, which show that handling folder names is still > buggy, losing synch after some renaming. .sbd folders do not follow the > movement. RESOLVED DUPLICATE is definitely not pertinent. > > Trouble started in step 3, when name change is not reflected in TB, but does in > Windows. Trouble became severe in steps 6 & 7. > > 1. Created sub-folder 2005 under Inbox. > Window files created: 2005, 2005.msf > Folder created: 2005.sbd > 2. Renamed sub-folder 2005 to 2005x. > Folder name changed to 2005x. > Window files 2005 & 2005.msf became 2005x & 2005x.msf; > Folder created: 2005x.sbd - folder 2005.sbd remained. > Files in sync, but folder 2005.sbd should not be there > 3. Renamed sub-folder 2005x to 2005y. > Folder name did not change. > Windows files 2005x & 2005x.msf became 2005y & 2005y.msf. > Folder created: 2005y.sbd > Now 2005.sbd, 2005x.sbd, 2005y.sbd are present and will remain forever > 4. Renamed sub-folder 2005x to 2005. > Folder name changed to 2005. > Window files became 2005 & 2005.msf. > 5. Renamed sub-folder 2005 to 2005x. > Folder name changed to 2005x. > Windows files became 2005x & 2005x.msf > 6. Renamed sub-folder 2005x to 2005y. > Folder name changed to 2005y but data disappears. > 7. Closed & reopened TB: both sub-folders 2005x & 2005y are present > Data is in sub-folder 2005x, sub-folder 2005y is empty. > Windows files are 2005y &2005y.msf Add step 8 : TB folder 2005x cannot be deleted by TB

DUP of Bug 65303. See Bug 65303 comment #31.

(In reply to comment #5) > DUP of Bug 65303. See Bug 65303 comment #31. Bug 230513 should be changed to CONFIRMED.

Confirming. Raanan Barzel, close as DUP, please. (Bug opener can resolve bug.)

(In reply to comment #7) > Confirming. > Raanan Barzel, close as DUP, please. (Bug opener can resolve bug.) I see you confirmed and at the same time status changes to NEW and you ask to close as DUP. I am now at a loss: while I understand that there is a problem in Mozilla, it has not been solved since 2001. The Bug in TB was displayed as RESOLVED while the problem was evidently still there. If Mozilla bug is not progressing and TB shows the bug as RESOLVED while it is not, something is wrong with the bug-resolving process. I will leave matters as they are for now.

The bug, as was greatly described by Raanan Barzel, still exists.

Can you try today's trunk thunderbird build? My fix for bug 65303 should have fixed this.

Works for me with trunk version 1.0+ (20050701).

excellent, duping. *** This bug has been marked as a duplicate of 65303 ***