Renaming folder to same name but different case not allowed

myk, this was a local folder, not an imap folder, right?

my guess is we do that because on some operating systems (win32), Foo is the
same file as foo.

we should check what 4.x does (on win32 and linux)

Seth, this is local folders. As in 4x we do not allow local folders with
different case but same name.

Yes, this is with local folders. I think the purpose of this bug has been
misconstrued. I'm not saying it should be possible to have two folders with the
same name but different case. I'm saying it should be possible to rename a
folder to its own name with different case.

In other words, if I have a folder called "mozilla", I should be able to rename
that folder to "Mozilla". I shouldn't be told there is already a folder with
that name when the only folder with that name is the one I am renaming.

4x also does the same thing. marking invalid again.

No, this is not invalid. As myk says, of course the user should be able to
change case on the same folder ("Mozilla" -> "mozilla")!

If it doesn't work in 4xp, it's a bug.

I'm sure there's a good reason for why 4.x did what it did.

on win32, the OS will not support this:

C:\>touch foo
C:\>mv foo FOO
mv: `foo' and `FOO' are the same file

local folders are just files, so the rename will fail.

4.x linux also doesn't allow you to rename folders to the same name.

the code (in 4.x and in mozilla) is all XP, we didn't do XP_UNIX for that rename
code.

for linux, the underlying os can handle "mv foo FOO", but there might be some
mailnews backend code that would break if we allowed it. (I haven't researched.)

it's a valid bug, since there are ways we *could* deal with this (with folder
pretty names), but marking wontfix.

workaround for myk: exit mozilla, rename that file on disk. but be careful not
to break any existing prefs or filters that point to that folder.

I was able to work around the problem (modulo bug 64463) by renaming the folder
to a different name ("mozilla" -> "foo") and then renaming it back to the name I
wanted with the correct case ("foo" -> "Mozilla"). The same technique could be
employed in the code to fix this problem.

Other major email apps supports renaming of this. I suggest we reopen this and
enforce myk's suggestion. Seth, Navin?

Seth, Navin:

any comments? Is this still won't fix or do you want me to reopen?

re-opening, myk's idea sounds good. we'll have to add extra code to check fix
new name is the same as the old name, excluding case (using strcasecmp), and if
so, do abc -> temp -> Abc.

*** Bug 126992 has been marked as a duplicate of this bug. ***

I just found this bug myself today, when trying to rename a folder.
(Win 2000, 0.9.9)

I think this bug is not so much about functionality as it is about polish. Can
you not imagine lesser computer people being amazed and confused about this
message that it couldn't rename the folder even though they chaged the
capitalization? I can (but then i do tech support, so... :)

So anyways, i think this is the sort of bug that separated the amateur projects
from the pro ones. As a test, i created a folder called "mozilla" in Outlook
Express, and renamed it to "Mozilla" without any difficulty at all. Hopefully a
keen developer can polish up this part of the code.

*** Bug 145653 has been marked as a duplicate of this bug. ***

Folks, I think there are two separate but similar bugs here:

1. When renaming folders, the new name should not be duplicate-checked against
the original folder name. Duplicate checking should be against all folders
except the one being renamed, since the name of the folder being renamed will
disappear in the process of renaming anyhow.

Note that this bug is independent of case, as can be seen when you try to
execute a rename that doesn't change anything, neither the name nor the case.
Just click on "rename folder", and then hit ENTER. This rename, although silly,
would not cause a problem since it doesn't change the state of the folders in
any way. So there should not be an error message. But instead the "A folder of
that name already exists" alert is thrown.

Fixing this would fix the problem described in comment 3, without having to
introduce any case-specific stuff.

2. The other issue is, should it be permissable to have two folders whose names
differ only by case. If so, then the rename check should be case-dependent, and
this is a separate bug. If not, then the case-independence of the renaming
check is not a problem, and only problem 1. exists. By all means, discuss the
issue, but I think you can fix and close this bug quite easily by fixing issue 1.

I too agree that this is a bug. It doesn't matter what the underlying problem
is, the user want to rename their folder to change the case, they ought to be
able to do so without the hassle of naming it something different first. To
argue otherwise shows that you have no understand of user interfaces and user
interaction and should be delegated to writing behind the scenes code that never
sees the light of a terminal screen.

I can't believe this thing has been in here since July 2001!

bcl

I'm also nerved to do the extra renaming by changing the case of letters.
Because i see that Seth said that it doesn't work with windows i have to add
following. I tried the steps within the command shell:

c:\>mkdir mozilla
c:\>rename mozilla Mozilla

And it works perfectly.
Why should the same operations not work within Mozilla?

*** Bug 144929 has been marked as a duplicate of this bug. ***

*** Bug 171628 has been marked as a duplicate of this bug. ***

*** Bug 209026 has been marked as a duplicate of this bug. ***

*** Bug 210815 has been marked as a duplicate of this bug. ***

*** Bug 219179 has been marked as a duplicate of this bug. ***

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113] (W98SE)

Confirming bug and workaroud.

Updating:
*(OS) Linux -> All, Linux + Windows.
*(S) Normal -> Minor, trivial workaround in comment 7.

Same bug in Thunderbird (at least 0.5)... don't know if I have to duplicate the
bug for Thunderbird ?

How much time before a 3 year old bug is being fixed ?
(even if not a vital one, I admit)

Confirming for Mozilla Thunderbird 0.5 (20040207)
It's not vital, but pretty anoying.

Confirming for Mozilla (2004050509) (WinXP) and mozilla-1.6 (SunOS).

*** Bug 236143 has been marked as a duplicate of this bug. ***

*** Bug 237563 has been marked as a duplicate of this bug. ***

As for the "workaround": exit mozilla, rename that file on disk. but be
careful not to break any existing prefs or filters that point to that folder.

Whomever suggested this has never worked at a helpdesk serving non-techie types
who don't give a rat's a** what the underlying technical issues are. The
real-world non-techie user sees a silly, petty restriction -- and as was also
said "It works in Outlook".

If you have to first rename the folder twice, then so be it:
mozilla -> $$temp$$ -> Mozilla

Could someone please tell me why fixing this bug is considered so difficult? It
seems like anyone set up to edit code in mozilla should be able to fix this
faster than they could edit the bug report. Perhaps I'm missing something.

I'm not currently setup to contribute, and I can't commit the time to do so now,
but this seems like it should literally be a 5-15 minute fix...

Any contributor should feel free to send me the relevant code sections, I'll fix
it, and then send it back to them to integrate and they can take the credit!

*** Bug 251156 has been marked as a duplicate of this bug. ***

*** Bug 241086 has been marked as a duplicate of this bug. ***

*** Bug 254416 has been marked as a duplicate of this bug. ***

*** Bug 259601 has been marked as a duplicate of this bug. ***

3 years? Wow. If this hasn't been fixed by the time the election is over, I'll
dig out my old programming books and take it myself.

And someone please remind me to do so.

*** Bug 264865 has been marked as a duplicate of this bug. ***

Regarding comment 29, it *would* be a 5-15 minute fix if not for bug 65303 which
is non-trivial to fix...

Bug 65303 is sinister in its effect(s) as some effects happen in the current
session and some persist across sessions and continue to cause erratic operation
weeks later...

Bug 104525 is Thunderbird bug for this problem.

*** Bug 292648 has been marked as a duplicate of this bug. ***

Even when you create a new folder with name "mozilla" delete it, so that the folder can still be found in trash, create a new folder named "mozilla" and try to delete it too, you will also get the message "A folder
with that name already exists.".

That's bug bug 66763.

maildir might need the same kind of change, if it checks for folder existance in the same way before adding a sub-folder.

We need somebody to test the patch on Windows. On the other OSes it is fine to change the case of a file name (representing the folder) on the filesystem level. Changed case means different name. But what happens on Windows?

FWIW the default file system option on Mac OS X (which I tested) is case-insensitive, but yes, someone should absolutely test on Windows.

Adam, can you check the maildir code in mailnews/local/src/nsMsgMaildirStore.cpp as David points out too? Otherwise the patch might not pass review.

I can take a look when I have a chance; do you know how I'd test that? Is it used for IMAP/POP/something else?

(In reply to Adam Rosenfield from comment #111)
> I can take a look when I have a chance; do you know how I'd test that? Is
> it used for IMAP/POP/something else?

I'd suggest writing an xpcshell test for this general feature. That would make testing maildir support fairly straightforward.

I can confirm the same issue on Thunderbird 15.0.1, Mozilla 5.0 on Debian 6.0.5. Thunderbird is installed from Mozilla and not the Debian repos.

Comment on attachment 645623
Proposed patch

Sorry this review took so long, between critical TB 17 bugs and build problems its been hard to fit this in.

Testing on Windows 7, this patch does not work. When I rename folder "test" to "Test", I end up with both "test" and "Test" in the folder pane. There seems to be 2 dbs open as well, as if I click on one folder, then the other, the db attempts to rebuild.

This really should have a unit test as well.

Also the original patch bit rotted, I'll upload by unbitrotted version.

Created attachment 670441
Unbitrotted patch

*** Bug 810740 has been marked as a duplicate of this bug. ***

*** Bug 840288 has been marked as a duplicate of this bug. ***

*** Bug 859701 has been marked as a duplicate of this bug. ***

...still an issue in TB 26 :/

*** Bug 968646 has been marked as a duplicate of this bug. ***

Still an issue in TB 24.5.0, Linux x86_84.
Walk around: to rename "abc" to "Abc", first rename "abc" to "xxx" and then "xxx" to "Abc".

Folder to be renamed should be excluded from existing folder list when comparing with new name.

*** Bug 958572 has been marked as a duplicate of this bug. ***

*** Bug 270726 has been marked as a duplicate of this bug. ***

Thirteen YEARS and counting. I wish people would spend even half the effort they spend on marking duplicate bugs on actually fixing the bug.

updating status to reflect reality, so someone else feels free to take up the draft patch

*** Bug 1065260 has been marked as a duplicate of this bug. ***

this bug was reported 13 years ago. seems like this is mozillas duke nukem. just wanted to report, that today i was confrontated with that bug too.

Same here, on thunderbird 31.3.0

(In reply to spam from comment #127)
> this bug was reported 13 years ago. seems like this is mozillas duke nukem.
> just wanted to report, that today i was confrontated with that bug too.

(In reply to Glenn Glazer from comment #124)
> Thirteen YEARS and counting. I wish people would spend even half the effort
> they spend on marking duplicate bugs on actually fixing the bug.

(In reply to Larry Xiao from comment #128)
> (In reply to Glenn Glazer from comment #124)
> > Thirteen YEARS and counting. I wish people would spend even half the effort
> > they spend on marking duplicate bugs on actually fixing the bug.
The problem is, those are not the same people...

(In reply to :aceman from comment #129)
> (In reply to Larry Xiao from comment #128)
> > (In reply to Glenn Glazer from comment #124)
> > > Thirteen YEARS and counting. I wish people would spend even half the effort
> > > they spend on marking duplicate bugs on actually fixing the bug.
> The problem is, those are not the same people...

So? The reply was to two similar comments from two different people, gathered together.

Aceman, given the high popularity of this bug, can't we use the workaround as an interim fix when
renaming foo to Foo:

sourcefolder=foo
targetfolder=Foo
if (lcase(sourcefolder) == lcase(targetfolder)) {
- first rename foo to foo.tmp_random
- then rename foo.tmp_random to Foo }

Renaming folders doesn't happen every day, so taking a split second longer doesn't matter.
That way, it'll work for all types of folders/OSs/POP/Imap no matter what (except for those where the server doesn't allow renaming).
Then, we can spend the next decades looking for the real fix. Or maybe this is the real fix, because even some servers don't accept changing capitalization only, so we'd elegantly trick those.
The only scenario where this might fail are extra long nested folder names at the limit, where we might fail to create the tmp target folder if the tmp path gets too long or such.

I'd think that is would even be the final solution, not a workaround. We can never know what filesystem we are really on (even if we knew, we do not know all the limit or all exotic systems).

We must just try it. On any system, if we detect the new name only changes in case, do the renaming dance comment 131 and comment 7 proposed. On on the high level TB does not allow 2 folders to exist if they only differ in case (in CheckIfFolderExists). So this dance can be already done in nsLocalMailFolder.cpp, I don't think we need to code it in all the backends (mbox/maildir).

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #131)
> The only scenario where this might fail are extra long nested folder names
> at the limit, where we might fail to create the tmp target folder if the tmp
> path gets too long or such.
To avoid this, you could just try to rename to fo1, fo2, ... foa, fob, ... until success. tmp may be already in use.

> because even some servers don't accept changing capitalization only, so we'd elegantly trick those.
+1

I've noticed a problematic behaviour as a consequence of this bug, which I've described in Bug 104525, but since this thread is related and more active, I thought I should mention it here too:

In TB 38.2.0 on OSX 10.10.5, when I try to rename a folder in a POP account, I do *not* get the error until I dismiss the rename dialog.

As a result, if I click "Rename" X times in the rename dialog (with no response from TB), it is only *after* I dismiss the rename dialog that I get a succession of X error messages.

For the purposes of changing the case, this problem will be redundant when this bug (Bug 92165) and/or Bug 104525 are resolved, but I've filed it as a separate Bug 1207212 since this error also happens in non-bug situations.

- RG>

*** Bug 1287718 has been marked as a duplicate of this bug. ***

*** Bug 1485853 has been marked as a duplicate of this bug. ***

Postbox would be willing to sponsor the development of this fix if anyone would like to work on this.

Requirements:

* Cannot be structured as an add-on (as those are no longer supported in Postbox)
* Cannot rely on changes or APIs made after 52.8 (as Postbox is currently based on this version)
* Must work on Windows 7, 8, and 10 and macOS 10.11 and higher.

If interested, let me know and we'll work out the details.

Created attachment 9013294
92165-v2.patch - rebased again

Carrying forward Kent's r-.

This actually works fine for a local folder, but it doesn't work for IMAP. If you rename folder "Tests" to "tests" you end up with two versions in the UI. In the subscribe dialogue you only get "tests" and there's also only one "tests.msf" file. After a restart, the "Tests" folder is gone. So the solution can't be far off. Of course it's missing the maildir part which shouldn't be hard to add.

Since this is one of the TB "papercuts" (https://wiki.mozilla.org/Thunderbird/Papercuts), maybe we can look at this bug one day soon now.

Since Ben is already working a bit on fixing some maildir issues and touching the relevant files, maybe he'd be a good candidate. Or maybe not since this would need Windows to test? Just take it as a suggestions since I can't allocate resources.

I did a bit of debugging. folderPane.js:2605, folder.rename(aName, msgWindow);, calls nsImapMailFolder::Rename() which calls nsImapService::RenameLeaf() and that opens this URL via GetImapConnectionAndLoadUrl():
  "imap://<email address hidden>@server:143/rename>.INBOX.TestMessages>.INBOX.testMessages"
Later we came into nsImapIncomingServer::OnlineFolderRename() and nsImapMailFolder::RenameClient() which does indeed call nsMsgDBFolder::PropagateDelete() as a comment in the patch suggests.

So that's all very well, but there appears to be some code missing to remove the no longer existing folder from the UI.

It does fit in quite nicely with what I've been looking at with the EmptyTrash() implementation, so I'm happy to look at it (and in fact, I just spent a couple of hours poking through the code from where Jorg left off - I'll write up my thoughts).

I can run a profile off a vfat filesystem (usb stick or loopback trickery) for case-insensitive filenames, I should be able to hit the same issues as on Windows.

There is an issue even on Linux: if I rename an imap folder "aaa" -> "Aaa", it looks fine in the GUI, but the old "aaa" directory will still be on the filesystem. So something isn't quite right there.

Here are my notes - mostly a braindump for my own reference:

Local Folders

nsMsgLocalMailFolder::Rename() performs these steps:

1) calls nsIMsgPluggableStore::RenameFolder() to rename the raw filesystem artifacts:
     * mbox/maildir
     * any .sbd dir
     * .msf file (actually, I'm not sure this should be done by the msgStore)
2) updates the new folder's pretty name
3) checks up on any filters which might be referencing the folder
4) calls RenameSubFolders() which recursively creates new child folders, checking for filter usage as it goes.
5) detaches the old folder from the parent (and calls progagateDelete() on it) and adds the new one.
6) tells the nsIMsgFolderNotificationService that the folder has been renamed.

IMAP folders

nsImapMailFolder::Rename() just tells the server to rename the folder.
Later on, they'll be a nsImapIncomingServer::OnlineFolderRename() coming in, where the local imap folder renaming is handled.
I haven't picked all the way through this yet, but quick observations are:
1) if it's a virtual folder, it just calls nsMsgDBFolder::Rename() and leaves it at that.
2) the pluggable message store isn't used.
3) it calls both nsImapMailFolder::RenameClient() and nsImapMailFolder::RenameLocal(). RenameLocal() seems to be primarily concerned with renaming the local filesystem artifacts, while RenameClient() handles the folder hierarchy and assort imap-specific stuff.

Quick thoughts:

- The IMAP path should use the pluggable mail store to handle the filesystem artifacts.
- there _should_ be a whole heap of common functionality that can be shared between local and imap (including the nsMsgDBFolder::Rename() that imap virtual folders use).
- There's a whole load of folder deleting and rebuilding going on, which seems unnecessary and overly-complicated.
It seems like it _should_ be possible to just rename folders in place, rather than just ditching them completely and rebuilding them... (ie filesystem rename, then patch up affected URIs etc)
- that said, I'm sure this bug can be addressed with a quick-n-nasty patch for now.

(In reply to Ben Campbell from comment #140)
> It does fit in quite nicely with what I've been looking at with the
> EmptyTrash() implementation, so I'm happy to look at it ...
Thanks. I was in to minds and almost about to cancel the NI since this is going ((too) far) into IMAP. But then on the other hand, we need to increase our backend knowledge of IMAP.

*** Bug 1708164 has been marked as a duplicate of this bug. ***

*** Bug 1739969 has been marked as a duplicate of this bug. ***

Perhaps the title should be changed, as it also affects imap folders.

*** Bug 1746346 has been marked as a duplicate of this bug. ***