But why? Why are they a bad idea besides “Windows does it and ‘Windows bad’”? Why is DNS case insensitive (example.com and EXAMPLE.com are the same), but not files (.Xauthority and .xauthority are different)?
Case insensitivity lines up with the average user’s expectations. For example, if I’m searching for a file, I want a case insensitive match. Because if I named a file “Resume.txt” and searching “resume” didn’t bring it up, I’d be pretty confused. Now imagine the average Joe trying it. Explaining to them case sensitivity won’t convince them it’s a good idea because “Resume” and “resume” are the same thing.
Should that work different for different languages? Imagine the mess. Maybe the file names aren't even written in any human language. Should we use English rules for all languages? Why? What makes English so special that English characters would be normalized, but characters from the native language of the user won't? Wouldn't that trip people up?
Case-insensitive file systems are mostly advocated for by those who only or mainly speak English and aren't aware of how much variety there is in the languages across the globe.
And even in English "us" is a pronoun, whereas "US" is a country.
EDIT: another question: should the normalization rules be changed when the language changes? Break backwards-compatibility?
If you bothered reading the link, all of these questions have been addressed long ago by folks are are more knowledgeable than either one of us.
The rules are spesific to each language, and are especially neccesary for languages thay have several alphabets. Without this functionality, efficient search is impossible.
This silly, forcefull and uninformed critisism is exactly the kind of behaviour i was talking about.
The point of those questions wasn't to see if there are answers to them. The point of those questions was to show that all answers to them are flawed.
Yes, the link provides one set of answers. (Except for the backwards-compatibility and changing language question.) But it doesn't solve the problem.
When you want case-insensitive search, it's the search tool's job to provide it. E.g. whenever you want to do a case-insensitive search inside a file, you pass "-i" to grep or click a checkbox in a GUI. You don't change the file system to normalize characters inside files.
From the link, it also seems like the main motivation for the change is compatibility with Windows software. In particular, it mentions that it isn't something that should be enabled globally in the file system. It really isn't a convenience for the user.
The article makes a good case for providing compatibility with Windows software. But not for much else.
"The point of those questions was to show that all answers to them are flawed."
Whats flawed? Where is it flawed? You provide no arguments at all!
"When you want case-insensitive search, it's the search tool's job to provide it."
I dont know if you didnt read it, or missed it, but the article clearlerly explains that the tool above the FS cannot do such a search performantly, it has to happen at the FS layer
"You don't change the file system to normalize characters inside files."
Where does this certainty come from? Why do you offer no technical argument to support your position? Is this by Pope's decree?
Can you demonstrate a tool that can search efficiently in different alphabets, or when the same character is presentes by different unicode codepoints?
Reading replies here convinces me even more that you just picked 'something something windows' and react like a bull does to a red rag.
Not a single good technical counterargument has beed presented
Ok, maybe this you will judge as something constructive: when the underlying medium is case-insensitive, your application cannot behave in a case-sensitive way. But frequently I care about case-sensitivity in my searches. I gave an example in my top-most comment: "us" vs "US". On the other hand, when the underlying medium is case-sensitive, the application can implement case-insensitivity on its own. I do it all the time. Sometimes I want to run "find . -name", sometimes "find . -iname", and the first one not because I forgot about the second.
> Reading replies here convinces me even more that you just picked 'something something windows' and react like a bull does to a red rag.
Completely missed. I appreciate a lot of design choices behind Windows and use it with pleasure. However, I judge this one aspect of it negatively. It's also a source of recurring problems with Git on Windows.
Windows itself has case-insensitivity largely for backwards-compatibility reasons (from the times of MS-DOS). The underlying filesystem (NTFS) itself is case-sensitive, it is the OS API that normalizes filenames, and is itself case-preserving, rather than case-insensitive, when it comes to writing files.
UPDATE: another point: I may want to have a directory with an image for every character of my alphabet with files named accordingly. With a case-insensitive filesystem I can't have an "a.svg" and an "A.svg" in the same directory.
Isn’t that an implementation detail of whatever tool you’re using for searching for files? I seem to remember most search utilities doing that already?
