268946 - DeleteFolder should not fail on name collision.

Status: RESOLVED DUPLICATE of bug 66763

(Thunderbird :: Mail Window Front End, defect)

Description

[David A. Cobb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041108 Firefox/1.0

I know that deleting a folder is realized by moving the folder-branch to the
"Trash" folder.  However, the operations are not semantically / mentally the
same from the user's viewpoint.  It is erroneous behavior to fail a deleteFolder
operation because "another folder (in Trash) has the same name."  

The simplest way for a user to overcome this PITA is to rename the folder being
delete to, e.g. OldFolderName#0nn.  This, or something similar, should be done
automatically by the program when a collision occurs.  

It is obvious, I imagine, that 'n' can just be incremented until no collision
occurs. 

Reproducible: Always
Steps to Reproduce:
1. Pick a mailfolder with some common name -- like "news" which one might
reasonably have within many many branches.  
2. Try deleting a couple of them.
3.

Actual Results:  
After the first "deletion" the trash folder contains a "news" subfolder.  The
second deletion fails.  The user is advised that another folder with that name
exists.

Expected Results:  
Tried a different name for the destination - recognizably derived from the
original, such as "news#001" "news#002", etc.

Of course, if you REALLY wanted to do it up right, you could record sufficient
information to undelete the folder: move it back where it came from.  But that's
more like "nice to have."

Comment 1

[Mike Cowperthwaite]

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