Tim Robinson wrote:
That's my point -- I don't believe case sensitivity has a place anywhere in the file system.
I believe the file system should support case sensitivity, but the OSes should not use it as being sensitive, but only aware. Or better yet, make it a setting. Since a sensitive FS can support all aware OSes, and an aware FS cannot support all OSes, I vote for a sensitive FS with a bit that says whether you should actually pay any attention to it on disk.
Or for Joe Average, make it check whether there are more than one, and if there aren't (99.999999999999% of the cases, except for makefile and Makefile usually) it just takes the only one.
Let's make I, l and 1 the same character too, why not? Typewriter people do it all the time (note: don't let them use your excel spreadsheet without teaching them about the 1's). And while you're at it, let's map leetspeek to roman characters too, so nobody is confused when we type 1337 c0mm3|\|75 right?
I, | and 1 are semantically different things. I is a letter. | is a symbol, e.g. used to denote piping on the command line. 1 is a number.
Even better, and exactly my point, they all look alike. The second one wasn't the pipe-symbol, it was the character L in lower case. How should a user differentiate? He will only see a file written as 1ist, list, |ist or Iist and will not know which it is. (number, char L, pipe, char i)
If I ask for a file called 'zog', I shouldn't need to remember whether I originally typed its name as 'zog', 'Zog' or 'ZOG'. It's the same name in any combination of cases. Sure, when I'm shown the file's name, I should be shown it in the original case, because I might like to see my files in Sentence Case or camelCase or WhateverThisCaseIsCalled.
True, but I still feel it should support sensitive file names.
A couple of other non-semantic differences that Unicode knows about are halfwidth vs. fullwidth characters and composited characters. In the Unicode BMP, there are separate sets of codepoints for half-width and full-width Latin characters. I might type the name of a file, on my imaginary Chinese keyboard, using full-width characters. Later on, I might do a search having typed the name with half-width characters. Full-width and half-width characters should compare the same when doing wildcards -- they may look different on screen, but semantically they're the same.
Composited characters consist of a base character (e.g. Latin lower case O, which looks like o) and one or more combining characters (e.g. combining diaeresis, which looks like ?). I might download a file called 'm?bius', where the author of the file spelled the '?' using an 'o' and a '?'. If I try to run that file from the command line using my imaginary German keyboard, I would enter the command name using a Latin lower case O with diaresis, which looks like ?. Combined character sequences and individual precombined characters need to compare to the same thing.
I happen to be dutch, and we have trema's (umlauts) and accents too
. I hate it when people do that, but I feel they should be compared identical too. (that goes for domain names too!)
If you can think of any examples where case-sensitivity in file names is useful for the user, I'd be glad to read them.
Most obvious and probably the only one: when reading from a system with a user that does use it. If you then don't support it, you're fucked. Since you can support it with a fallback locate for non-sensitive names, it should not hurt.
