Closed Bug 230513 Opened 21 years ago Closed 19 years ago

Rename dose not work properly on subfolders

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 65303

People

(Reporter: raanan, Assigned: mscott)

Details

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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
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
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(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
(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.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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 ***
Status: NEW → RESOLVED
Closed: 21 years ago19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.