2 ms·

I find case-insensitivity (as both Mac OS X and Windows do it) user-hostile. So, there's a counter-anecdote. But, I believe all that proves is that in many cas

I find case-insensitivity (as both Mac OS X and Windows do it) user-hostile. So, there's a counter-anecdote. But, I believe all that proves is that in many cases, "what I'm used to" is the same as "easy and intuitive". There is often no one true way to make something complex easy and intuitive, and sometimes the "easy way" is the way you're used to (but for someone used to another way, it won't be easy). In this case, in the absence of compelling evidence that case-insensitivity is a net win for the user, the simpler implementation is probably the right one. The number of bugs over the years caused by insensitivity and Unicode mapping and such, is probably further evidence favoring simplicity. Also, the average Mac user doesn't even know they have a command line (seriously, I can't remember ever saying to a casual Mac user, "Open terminal" and have them say anything other than, "I don't know what that is" or "I don't have that"). There's no reason a higher layer can't make case-insensitive decisions for the user (say, searching for "the clash" will find music by "The Clash"), which doesn't require the freaking filesystem to make those kinds of guesses. Having this happen at the filesystem layer has always seemed utterly mad, to me. And, having it happen at the higher layers is how Linux and UNIX software has always handled it. Somehow we muddle through with the filesystem being entirely naive about the letter "a" being sort of the same as "A" (for humans).

wodenokoto 12y ago
How is it user hostile? I think it is very reasonable to say that common users of the Alphabet expects "Documents" and "documents" to be the same word. I think it is even safe to assume most readers consider "john" and "John" the same name, while "Jon" and "John" are not. I can't think of any situation where I have needed to have two differently capitalized files reside in the same folder, but I can remember dozen of times I've been annoyed by it. My point is, there are arguments to calling case-sensetivity for user hostile, but you don't present any to counter it.
- SwellJoe 12y ago
  Most visibly: Tab completion can get the wrong/unexpected file (note that it doesn't have to be the same filename to cause this problem...if I'm expecting "my<tab>" to complete to "my program", because it is the only file starting with "my" but instead it completes to "My Documents" or requires a double tab and more specificity from me, that's an annoyance). Windows tab completion is perhaps the perfect storm of annoyance for me, with regard to case insensitivity. It'll complete to the first thing it sees case insensitively and then require cycling through all matches to find the desired file. This would also break file globs, or at least my expectation of what file globs should do. This is, of course, a mild bit of user hostility, but it is less friendly and harder to use, to me, than case sensitivity. As I noted above, it's mostly a matter of what you're used to, but in the absence of a reasonable case that case insensitivity makes life easier for users, the right implementation is the simpler one. The more dangerous stuff is where the OS decides that one file is actually a different file, through character conversion or through Unicode mapping. And, that, (not) coincidentally, is where serious security bugs were found in git. And, git is not alone in running into these problems. In short, I find it annoying that the OS would decide it knows what I want, when I ask for something else. But, more importantly, it has been proven occasionally to be dangerous, and often to be error-prone, in implementation. But, on that front, I'm probably just going to repeat what Linus said less effectively.
  - Camillo 12y ago
    It doesn't do that on OS X.
- lomnakkus 12y ago
  Would you expect "install" and "Install" to be the same name? In most languages you'd be right to, but if your FS were using the Turkish locale, you'd be wrong[0]. So now we need to stamp a "locale" on the file system to avoid problems -- but then how do you carry that over when you're e.g. unpacking a zip you received from a Turkish person and your own file system has a different idea of what characters are the same or not? (I suppose I should say "glyphs", but even that's quite iffy in unicode terms.) I'm not sure that having such a fundamental thing as whether two file names are the same be dependent on such complex things as unicode, canonical forms, etc. is a good idea. I won't comment on whether it's more user-friendly or hostile -- I have no data to back that up anyway. It's ridiculously complex and that's what I would base my decision on. At least using "a string of bytes" as the file name is simple conceptually and pretty hard to get wrong. [0] en.wikipedia.org/wiki/Dotted_and_dotless_I
- kbenson 12y ago
  Obviously, the solution is to just assign a numerical index to every file, and require filenames to be contiguous integers. Problem solved. In reality, there is a sliding scale between usefulness and complexity in filenames, and where one person thinks the optimal trade-off point is may not match what others think. Many filesystems have chosen (rightly so in my opinion) to just allow as much as possible, and let convention and the application layer sort it out. There are many, many complexities to character normalization and casing (think unicode and languages where multiple characters may be combined into a single separate character, or where there are choices to make on the correct way to change case based on the word itself), and again the problem is to be where to draw the line at what the filesystem should do for you. The real problem is that people think that filesystems let us name files with words, when really we are just tagging file with characters. Words, as used in language, are an entirely more complex beast, and IMHO, entirely the wrong think a filesystem should care about.

wodenokoto 12y ago

How is it user hostile? I think it is very reasonable to say that common users of the Alphabet expects "Documents" and "documents" to be the same word. I think it is even safe to assume most readers consider "john" and "John" the same name, while "Jon" and "John" are not. I can't think of any situation where I have needed to have two differently capitalized files reside in the same folder, but I can remember dozen of times I've been annoyed by it. My point is, there are arguments to calling case-sensetivity for user hostile, but you don't present any to counter it.

SwellJoe 12y ago
Most visibly: Tab completion can get the wrong/unexpected file (note that it doesn't have to be the same filename to cause this problem...if I'm expecting "my<tab>" to complete to "my program", because it is the only file starting with "my" but instead it completes to "My Documents" or requires a double tab and more specificity from me, that's an annoyance). Windows tab completion is perhaps the perfect storm of annoyance for me, with regard to case insensitivity. It'll complete to the first thing it sees case insensitively and then require cycling through all matches to find the desired file. This would also break file globs, or at least my expectation of what file globs should do. This is, of course, a mild bit of user hostility, but it is less friendly and harder to use, to me, than case sensitivity. As I noted above, it's mostly a matter of what you're used to, but in the absence of a reasonable case that case insensitivity makes life easier for users, the right implementation is the simpler one. The more dangerous stuff is where the OS decides that one file is actually a different file, through character conversion or through Unicode mapping. And, that, (not) coincidentally, is where serious security bugs were found in git. And, git is not alone in running into these problems. In short, I find it annoying that the OS would decide it knows what I want, when I ask for something else. But, more importantly, it has been proven occasionally to be dangerous, and often to be error-prone, in implementation. But, on that front, I'm probably just going to repeat what Linus said less effectively.
- Camillo 12y ago
  It doesn't do that on OS X.
lomnakkus 12y ago
Would you expect "install" and "Install" to be the same name? In most languages you'd be right to, but if your FS were using the Turkish locale, you'd be wrong[0]. So now we need to stamp a "locale" on the file system to avoid problems -- but then how do you carry that over when you're e.g. unpacking a zip you received from a Turkish person and your own file system has a different idea of what characters are the same or not? (I suppose I should say "glyphs", but even that's quite iffy in unicode terms.) I'm not sure that having such a fundamental thing as whether two file names are the same be dependent on such complex things as unicode, canonical forms, etc. is a good idea. I won't comment on whether it's more user-friendly or hostile -- I have no data to back that up anyway. It's ridiculously complex and that's what I would base my decision on. At least using "a string of bytes" as the file name is simple conceptually and pretty hard to get wrong. [0] en.wikipedia.org/wiki/Dotted_and_dotless_I
kbenson 12y ago
Obviously, the solution is to just assign a numerical index to every file, and require filenames to be contiguous integers. Problem solved. In reality, there is a sliding scale between usefulness and complexity in filenames, and where one person thinks the optimal trade-off point is may not match what others think. Many filesystems have chosen (rightly so in my opinion) to just allow as much as possible, and let convention and the application layer sort it out. There are many, many complexities to character normalization and casing (think unicode and languages where multiple characters may be combined into a single separate character, or where there are choices to make on the correct way to change case based on the word itself), and again the problem is to be where to draw the line at what the filesystem should do for you. The real problem is that people think that filesystems let us name files with words, when really we are just tagging file with characters. Words, as used in language, are an entirely more complex beast, and IMHO, entirely the wrong think a filesystem should care about.