92165 - cannot rename a local folder to its current name with different case

Status: NEW

(MailNews Core :: Database, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

Trying to rename a folder to its current name with some letters having a
different case (f.e. changing "mozilla" to "Mozilla") gives the error "A folder
with that name already exists.".

Steps to Reproduce:

1. Create a folder called "mozilla" under "Local Folders".
2. Right-click the folder and select "Rename Folder".
3. Change the name of the folder to "Mozilla" and click "OK".

Expected Results:

The name of the folder changes to "Mozilla".

Actual Results:

The error message "A folder with that name already exists." appears.

Tested On: Linux nightly 2001-07-24

Comment 1

[(not reading, please use [e-mail] instead)]

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)

Comment 2

[Navin Gupta]

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

Comment 3

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 4

[Navin Gupta]

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

Comment 5

[Håkan Waara]

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.

Comment 6

[(not reading, please use [e-mail] instead)]

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.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 8

[Håkan Waara]

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

Comment 9

[Sheela Ravindran]

Seth, Navin:

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

Comment 10

[(not reading, please use [e-mail] instead)]

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.

Comment 11

[Tom Kalmar]

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

Comment 12

[Jonathan Stewart]

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.

Comment 13

[Sheela Ravindran]

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

Comment 14

[Drew Devereux]

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.

Comment 15

[Brian C. Lane]

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

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 17

[Jo Hermans]

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

Comment 18

[Jo Hermans]

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

Comment 19

[Jo Hermans]

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

Comment 20

[Jo Hermans]

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

Comment 21

[Malte Rücker (mbr)]

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

Comment 22

[Serge Gautherie (:sgautherie)]

[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.

Comment 23

[jigho]

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)

Comment 24

[Marcus Proest]

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

Comment 25

[Johannes Koskinen]

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

Comment 26

[Asa Dotzler [:asa]]

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

Comment 27

[Asa Dotzler [:asa]]

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

Comment 28

[lohphat]

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

Comment 29

[Owen]

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!

Comment 30

[R.K.Aa.]

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

Comment 31

[Jo Hermans]

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

Comment 32

[Jo Hermans]

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

Comment 33

[Frankie]

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

Comment 34

[Frankie]

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.

Comment 35

[Erik Fabert]

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

Comment 36

[Frank]

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...

Comment 37

[WADA:World Anti-bad-Duping Agency]

Bug 104525 is Thunderbird bug for this problem.

Comment 38

[Matthias Versen [:Matti]]

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

Comment 39

[wurstbrot]

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.".

Comment 40

[Magnus Melin [:mkmelin]]

That's bug bug 66763.

Comment 41

[Andreas Kleinert]

Just wanted to confirm the case-sensitivity (i.e. case-insensitivity) renaming problem problem also for Thunderbird 1.5.0.7 (Windows).

For example: you'd like to track some SuSE-related mailing list and created some filter for it, redirecting mails to the "SuSe-ML" folder. Then you notice the spelling mistake and want to rename it to "SuSE-ML" - does not work, because the folder 'already does exist...'

As mentioned below, the same error of course also occurs, if you just leave the name as it is, and press ENTER in the rename dialog.

Comment 42

[Simon Reinhardt]

Same in Thunderbird 1.5.0.9 on Windows (surprise, surprise ;) ).

Comment 43

[Daan Timmer]

Same problem still excists in Thunderbird 1.5.0.10 on Windows XP SP2.

I am also wondering why, (it is said anywhere above) they are using a "mv foo Foo" command and not a rename command.

If I press F2 in explorer on any file name, and change foo to Foo then it works, so why should it not work for Thunderbird?

Comment 44

[Magnus Melin [:mkmelin]]

It would not be a problem on XP, only on Win9X. And I suppose to some degree for fat partitions on linux (for multi-boot sharing mail folders). mv is the unix rename command...

Comment 47

[cooler]

The problem still exists in Thunderbird 2.0.0.6 (using Win XP Pro).

Comment 49

[Age Bosma]

6 years and still present. What are the objections against fixing this bug?

Comment 50

[Karsten Düsterloh]

> 6 years and still present. What are the objections against fixing this bug?

You didn't attach your patch yet. 

Comment 51

[Age Bosma]

(In reply to comment #50)
> > 6 years and still present. What are the objections against fixing this bug?
> 
> You didn't attach your patch yet. 
> 

Hehe, I knew I forgot something ;-)

Comment 56

[dayslipper]

Almost 7 years.

Comment 57

[Joshua Cranmer [:jcranmer]]

(In reply to comment #56)
> Almost 7 years.
> 

Comments like these are not helpful.

If you want it that badly, you could just fix it up yourself and post a patch. The fact is that there are at least two known workarounds, so this isn't a terribly big deal.

In addition, there are also several more pressing issues currently going on with mailnews core that are competing for time.

Comment 58

[dayslipper]

I hope that it'll be OK in TB 3.0.

Comment 62

[Craig Stephen]

I am seeing this - or maybe just something similar - in Thunderbird 3.0b2:

create folder "test"
create subfolder "Aaaa"
rename subfolder to "aaaa"

for a while, two subfolders show up - "Aaaa" and "aaaa".
Shortly thereafter, "Aaaa" disappears - so it looks like the operation worked!
But... a bit later... "aaaa" disappears, too.

So now my subfolder - and everything in it - are unfindable.

If I start TB 2.0.0.21, however, "aaaa" is present.

If I restart TB 3.0b2, "aaaa" is still missing.

This seems like a problem, since, unlike the scenarious described above,
there's apparently no workaround from within TB 3.0b2.

Comment 63

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #62)

Local mail folder? IMAP folder? Tb on Linux? on Mac OS X? or on Win?
(file system of case-sensitive filename or of case-insensitive filename)
If IMAP, see Bug 484329.

Comment 64

[Craig Stephen]

Oops - thanks WADA.

IMAP folder, WinXP Pro SP2.

Thanks for the cross-reference to Bug 484329;
I will have a look.

Curiously, a short time after posting this,
the original folder *reappeared* - but my
test case, documented above, is still missing
in action.  Perhaps this is some IMAP server
problem.

Comment 65

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #64)
> Perhaps this is some IMAP server problem.

External phenomenon depends on case sensitivity of file name/IMAP folder name at both IMAP server and local PC. Bug 484329 is probably IMAP server on Unix(case sentisitve) & Tb on Linux case, and Tb mis-handles it then folder is hidden. If IMAP of IIS on MS Win, different phenomenon can occur. (example. IIS on MS Win retrurn OK to create "aaa", but returns folder name of "AAA".) 
Is your IMAP server case sensitive on IMAP folder name and filename?

Anyway, this bug is for rename of local mail folder.
If your problem with IMAP is different from Bug 484329, get IMAP log, and open separate bug, please.

Comment 66

[c300331]

I can't believe I started this SEVEN years ago and the bug is still UNFIXED.
Someone's already commented Outlook doesn't have the problem yet you folks piddle around arguing about "work arounds" going outside the OS and renaming, etc. Do you really think the general user does that kind of stuff? All he/she sees is a program that hasn't quite got it!

Comment 67

[wayne lydecker]

Please don't fix this.  I found the bug this morning, which quickly led me to this report.  I haven't been so amused in a long time.  This problem has been around since 2001 and it still is a bug!  The amount of time and energy to fix the problem would have been a fraction of that used defending why it shouldn't be fixed.  Until silly bugs like this are fixed, its hard taking Thunderbird seriously.  Thanks for the laugh.  I'll check in every now and then to keep track of the latest developments here.

Comment 70

[Juergen]

Hi!

I noticed now in TB 3 B3 the same 'bug':

http://img4.abload.de/img/imgdxtr.gif

So i worked it this way around:
Folder Name is 'Test 2' and TB dont let it me to rename it to 'TEST 2'. So i renamed the Folder to 'BlaBla'. Then i renamed 'BlaBla' to 'TEST 2' -> finish! ;-)

Comment 73

[Dan Mosedale (:dmosedale, :dmose)]

I don't think this is so high-leverage that it qualifies as "wanted", but it's not "wontfix" either since we'd accept a patch if it were to appear, so just resetting the status to nothing.

Comment 74

[Douglas G. Danforth]

This bug was first reported 9 years ago! 2001-07-24 15:21:46 PDT


Why hasn't it been fixed!!!!!!!!!

Mozilla you get a very, very, poor rating for this.

Comment 75

[c300331]

I've been asking that same question for those nine years!
Even the nasty comment, "You can do it in Outlook" doesn't get a response.
This looks very unprofessional for what s(c)ould be an excellent mail reader.

Comment 78

[Edam]

Happy 10-year anniversary!  :o)

Comment 81

[:aceman]

David is probably not working on this.

Comment 82

[Steve]

Just wanted to point out that this bug is still valid in 12.0b1 - Just for grins and giggles I've downloaded the source.

- Windows 7 64-bit

Comment 83

[thE_iNviNciblE]

rename from "bug" to "Bug" is still not possible in thunderbird 11.0.

Comment 84

[:aceman]

This seems very similar to bug 66763. I think a very similar approach and code could be used here.

Comment 85

[Brian Bowling]

This appears to still be an issue in 13.0.1.

Comment 86

[Megac]

This is fixed on Linux Mint 13 with Thunderbird 13.0.1 using IMAP...

Comment 87

[nick]

This bug has been reported 11 years ago (!), and is still there. It is almost funny...

Comment 88

[S. Kerman]

I wish I could participate in your generosity of spirit.  But it's clear that their priorities are to produce new poorly tested versions with even more blatant bugs that show up within 15 minutes of installation.  They can't be bothered fixing the old bugs.  

That's why I don't bother reporting bugs anymore.  I have learned the bitter lesson that installing a later version can be a big mistake, with the new version, one that has been out for a while and ought to be an improvement, ends up being a total disaster, with things that worked for the last 10 years suddenly broken.

Comment 89

[S. Kerman]

I wish I could participate in your generosity of spirit.  But it's clear that their priorities are to produce new poorly tested versions with even more blatant bugs that show up within 15 minutes of installation.  They can't be bothered fixing the old bugs.  

That's why I don't bother reporting bugs anymore.  I have learned the bitter lesson that installing a later version can be a big mistake, with the new version, one that has been out for a while and ought to be an improvement, ending up being a total disaster, with things that worked for the last 10 years suddenly broken.

Comment 90

[P. Harper]

Oh come on. I know it's annoying that some bugs linger for such a long time, but on the other hand 

a) this bug is an extremely minor nuisance with a trivial workaround
b) on the whole, Thunderbird is an excellent piece of software that I've enjoyed using for many years now. 

I think it's somewhat disrespectful to the developers to go and post bitter and dismissive comments about Thunderbird because of minor glitches.

Comment 91

[Joshua Cranmer [:jcranmer]]

(In reply to Megac from comment #86)
> This is fixed on Linux Mint 13 with Thunderbird 13.0.1 using IMAP...

This bug is only an issue on case-insensitive filesystems, so it pretty much affects only Windows.

To everyone else: it is known that this is an issue. Complaining about this bug will not increase its priority. In fact, it will tend to decrease the likelihood that developers will work on it. Please do not comment on this bug unless you are working on, or commenting on, a proposed solution to the problem. See <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> and please follow its rules.

Comment 92

[S. Kerman]

Only affects Windows, huh...  Are there statistics somewhere on how many Windows downloads have occurred over time VS other operating environments?

Comment 93

[Jean-Philippe Fleury]

(In reply to Joshua Cranmer [:jcranmer] from comment #91)
> This bug is only an issue on case-insensitive filesystems, so it pretty much
> affects only Windows.

It doesn't only affect Windows. I have this bug on GNU/Linux, and see the bug description: "Platform: All All".

Comment 94

[:aceman]

And this bug is not dead, see comment 84.

Comment 95

[:aceman]

Yes, this affects Linux too (with POP3 account).

Comment 96

[Adam Rosenfield]

Attachment: Proposed patch

Happy 11th birthday!  I have for you a present.

Feedback welcome.  The bug has nothing to do with case-insensitive file systems (the underlying file renames are performed with rename(2) on Linux/OS X and MoveFileExW on Windows, which can handle case changes just fine).  The bug is entirely in the way Thunderbird was handling names.

I've only tested this on OS X.

Comment 97

[:aceman]

Oh, nice present :)
Does mailnews/local/src/nsMsgMaildirStore.cpp need a similar touch like nsMsgBrkMBoxStore.cpp ?

Comment 98

[Douglas G. Danforth]

Ah, from a 'user' point of view presenting code is not a solution.  This needs to be incorporated into the next Fire bird release.

Comment 99

[Adam Rosenfield]

(In reply to :aceman from comment #97)
> Oh, nice present :)
> Does mailnews/local/src/nsMsgMaildirStore.cpp need a similar touch like
> nsMsgBrkMBoxStore.cpp ?

I don't know, I'm not familiar enough with the code base.

Comment 100

[:aceman]

Neither am I:) I just think that the implementation of maildir-lite can have the same problem as the mbox implementation (that you changed).

I'll try the patch soon on Linux.

Comment 101

[:aceman]

Comment on attachment 645623 [details] [diff] [review]
Proposed patch

Great, works for me on mbox store on Linux.

Comment 102

[:aceman]

Adam, welcome to bugzilla and we welcome your patches:)
Do you know whom to request review from?

Comment 103

[Adam Rosenfield]

(In reply to :aceman from comment #102)
> Do you know whom to request review from?

No clue, any suggestions?

Comment 104

[:aceman]

You can find reviewers here: https://wiki.mozilla.org/Modules . Just find the module the bug is in (as seen in the Product + Component fields). Of course there are some outdated data and people overlapping modules.

Comment 105

[Joshua Cranmer [:jcranmer]]

The patch, at a minimum, needs a test. I don't know if a mozmill test or a xpcshell test would be better here.

Comment 106

[Adam Rosenfield]

I'll see what I can do for a test, but since I'm doing this in my spare time I can't promise any expediency (not that anyone expects that here given the age of this bug...).

Comment 107

[David :Bienvenu]

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

Comment 108

[:aceman]

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?

Comment 109

[Adam Rosenfield]

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

Comment 110

[:aceman]

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.

Comment 111

[Adam Rosenfield]

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?

Comment 112

[David :Bienvenu]

(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.

Comment 113

[root.packet]

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 114

[Kent James (:rkent)]

Comment on attachment 645623 [details] [diff] [review]
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.

Comment 115

[Kent James (:rkent)]

Attachment: Unbitrotted patch

Comment 119

[klonos]

...still an issue in TB 26 :/

Comment 121

[Cyril]

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.

Comment 124

[Glenn Glazer]

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

Comment 125

[Wayne Mery (:wsmwk)]

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

Comment 127

[spam]

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.

Comment 128

[Larry Xiao]

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.

Comment 129

[:aceman]

(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...

Comment 130

[Glenn Glazer]

(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.

Comment 131

[Thomas D. (:thomas8)]

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.

Comment 132

[:aceman]

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).

Comment 133

[Ulf Zibis]

(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

Comment 134

[realgrouchy]

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>

Comment 137

[sherman]

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.

Comment 138

[Jorg K (CEST = GMT+2)]

Attachment: 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.

Comment 139

[Jorg K (CEST = GMT+2)]

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://[e-mail]@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.

Comment 140

[Ben Campbell]

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.

Comment 141

[Ben Campbell]

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.

Comment 142

[Jorg K (CEST = GMT+2)]

(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.

Comment 145

[adrien.rybarczyk]

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

Comment 147

[Erik Z]

There are still Thunderbird users who would appreciate a fix to this issue, as it continues to persist on recent versions (I use 115.18.0 on Linux Mint). Thank all of you for your contributions. But when can we expect to see the result of these efforts to be released for usage?
If a solution for imap-folders is (too) complicated, it would constitute a step forward to release a solution for the rest, i.e. for local and pop3-folders.