There are very real problems with HFS+ related to reliability and data corruption. It really is quite bad. Linus's argument is silly, however, and purely a matter of taste. Case insensitivity certainly isn't the reason that HFS+ is bad.
I disagree. I don't think a program should make any assumptions about the filesystem namespace—it's up to the user how they want to configure it.
Case sensitivity may bother users sometimes, but the filesystem is not the right place to solve that problem.
To me it smacks of a rather egregious failure to grasp Postel's law. And case-sensitivity is just bad UX for the 99% of computer users who aren't programmers or IT; perhaps it makes sense on Linux but Windows and OS X are dealing with a different audience and Linus's failure to give that fact some credit makes him come across as tone deaf.
That's a pretty major downside, and I think the back story for his dislike of it.
How about Straße, STRASSE and strasse?
For an American audience, how about Résumé and RESUME and resume?
How about Ⅸ and IX? Hint: https://en.wikipedia.org/wiki/Unicode_equivalence#Normalizat...
The answer to all that is that it depends on the user and their locale settings. So to get this right you would have to pass the locale settings into system calls that go into the filesystem so it can do the right thing on every call. But then what happens if the locale later gets changed? Before some file names may be considered equivalent, but with the new one they are different and things break. Ok how about a system wide locale setting that can't be changed? Are you going to require a disk reformat each time a different user is on the system, or a multilingual user who travels?
The right solution is exactly what Unix did in the first place. The filesystem stores names exactly as is without having to deal with locales. User space is then responsible for doing the right thing for a user. For example a word processor can treat Résumé and Resume as the same for Americans in file selection dialogs.
User space already has to deal with all this, for example by sorting file names. Here is how hard that is http://www.unicode.org/reports/tr10/ and a simple example is if z comes before or after ö. Or when showing a list of Swedish names to a German user do you use Swedish or German sort order?
A similar analogy is dealing with time. The best approach is to store the time as UTC in the filesystem and let user space show it in whatever way is relevant for the user. On the other hand if you store local time in the filesystem, you will end up in a world of hurt trying to work around that. (UTC to local time is a lossy conversion making local time back to UTC hard to work out.)
- Filesystem implementation (actual on disk bytes)
- Filesystem compatibility (adjustments to OS semantics)
- Generic filesystem layer in the kernel
- System call interface (between userland and kernel)
- Userland low level library (eg system call wrappers)
- Higher level libraries (eg libc)
- User interface libraries
- App level modules & libraries
The problem with the filesystem being case insensitive is that is the first level above, where there is virtually no context or user information. That is the hardest place to work out if the user considers Résumé and RESUME to be the same. The lower down the list the easier it gets. The important point is that how you store things and how you present does not need to be the same.
Command line tools typically use the libc level of things. It is perfectly possible to make that level so the system appears case insensitive (another poster mentioned Windows doing that).
Your Unix command line experience is very much affected by your locale. For example the ls command does the following:
- Sorts filenames
- Displays sizes (different locales have different conventions for floating point representation, digit grouping etc)
- Displays times
Environment variables like $LANG, $LC_*, $TZ etc control this in Unix.
Individual programs can also alter behaviour. For example bash can be configured to do case insensitive filename completion.
TLDR: while case insensitivity is a nice user experience for humans, it is awful for the lower layers including filesystems. The closer a program is to a human, the easier it is to give that nice user experience. There is no requirement for a case insensitive user experience to then make filesystems also implement that. And as my examples show, they couldn't do it correctly anyway.
Let's take other non-latin characters, like accented letters or cyrillic. Some of these alphabets have letters that act as 'a' but are not 'a'. Some of these alphabets have glyphs that look like 'a' but are not 'a'. All of these glyphs are encoded using different codes as seen by a machine.
If you want to support 'a' == 'A', then I could argue that I would want you to support 'a' == 'A' == <letter in cyrillic that means 'a'>. It is a very slippery slope, in my opinion. Logically, I would rather have 'a' and 'A' separated to avoid ambiguity, but feel free to disagree.
macadam.doc might be about a type of road construction.