Case Sensitive Rename (on some filing systems?)
I have a file called "filename", I wish to rename it as "Filename" but Thunar tells me that I can't rename the file with the same name I'm renaming it from.
Possible Cause
BugTrak archive #2308 suggests this is only happening on some filing systems with a suggestion that a previous bug reporter was using a file system that did not support Case Sensitivity. The bug was closed "invalid".
I'm experiencing this on a FAT32 system which does support case sensitive filenames.
There's more information below regarding FAT32 having two labels for each filename for FAT16 backwards compatibility but to cut a long story short FAT32 has two labels for each file. One is 8.3 format where "filename"="FILENAME"="fIlEnAmE", but there's a long filename label for each file which stores a case sensitive label for each file.
Checking against the 8.3 label would result in the view that renaming "filename" to "Filename" since it appears in 8.3 format to be the same case insensitive filename.
Renaming Complications with 8.3
There are further complications in renaming FAT32 files in that if "filename" (FILENAME) already exists and you want to rename "dataname"(DATANAME) to "Filename"(FILENAME), you can't have two 8.3 "FILENAME" entries, so the latest file that would otherwise have that name is given the 8.3 label "FILENA1" or if that exists "FILENA2", "FILENA~3" etc.
In Depth
FAT32 does support Case Sensitive filenames unlike its FAT16 predecessor with which FAT32 provides backwards compatibility by having a two stored filenames {fn1,fn2} for each file. The one stored filename {fn1} is in "8.3" format "12345678.123" which MS-DOS<=6.22 will see but there's a second stored filename for each file which will be viewable by DOS >= 7 (i.e. Windows 95 +) {fn2}.
On FAT32 the filenames "Filename" and "filename" are two completely different files according to their {fn2} entries but they may show up as having very similar {fn1} entries, so similar in fact that it will be required to know what the last {fn1} looking entry was in order to determine what its value is.
From the perspective of Windows 95:
In an empty folder:
-
I create "filename.txt". The DOS gives it an {fn1} of "FILENAME.TXT" and an {fn2} of "filename.txt".
-
I then create "Filename.txt". The DOS gives it an {fn1} of "FILENA~1.TXT" and an {fn2} of "Filename.txt"
If do those two steps in reverse, then "Filename.txt"="FILENAME.TXT" and "filename.txt"="FILENA~1.txt"
Adding a third "fIleNaMeS-cAn-Be-CaMeLcAsE.tXt" will result in an {fn1} of FILENA~2.TXT and the full and propoer filename stored as expected in {fn2}.
Probably Cause Reiterated
In a situation where there is only one filename on the system then looking only at {fn1} and ignoring {fn2}, it appears that
"Filename.txt"{fn2} = "FILENAME.TXT"{fn1}
IS THE SAME AS
"filename.txt"{fn2} = "FILENAME.TXT"{fn1}
but this is because only the {fn1} entry is being looked at.
FOR ENTERTAINMENT
So here rests my dissertation on what I know about FAT32 filenames (which scarily isn't very much).
I thought Id do a bug report so I googled Thunar bug report then I clicked help|about and evetually discovered #2308 then realised thats an archaic bugtracking system so I found the latest bug tracking system and I searched for rename bug reports and I found nothing so I clicked on "report issue" and then it asked me sign in and then I was like "for a bug this small?" but then I saw "sign in with github" so I signed in with github, having filled out my email address and password then opened up my email to do two factor authethentication and I know that as soon as I click the SUBMIT button below there's going to be more hoops to jump through to fill out this bug report.
Maybe this is all to provoke to a more verbose response from the hoop jumper.
To think ... I could have just renamed that file to something else and renamed it to the case sensitive different version and here I am typing my little heart out. I suppose whoever fixes these things has to
(need a break) ? (entertaining text) : (more fecking code)!