Linus Torvalds: Apple's HFS+ is probably the worst file-system ever

(please note the tongue firmly planted in cheek, even if a lot of people actually DO work like this. which is terrifying)

The 1900 epoch needs additional code to handle the fact that 1900 was not a leap year. Why not the UNIX epoch? Well that's another question entirely.

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.)

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.

That's a pretty major downside, and I think the back story for his dislike of it.

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.

macadam.doc might be about a type of road construction.

On the other hand, "myfiles" and "my files" have different numbers of characters. They sound different in your head, and you can easily point to the difference. It's the same as typing "alien" versus "a lien".

Spaces are lexically significant in the English language because they indicate the breaks between words. "My files" are two English words that convey meaning to English speakers; "myfiles" is not a word at all and is meaningful only if we charitably insert the spacing necessary to make them meaningful.

Capitalization does not impact meaning to English speakers in the same manner; "my files" and "My files" are understood to mean the same thing. Capitalization is in this case merely an artifact of sentence positioning and the like. It's orthographic convention and nothing more.

Thus, to make the user have to understand that what is a meaningless distinction in English is a meaningful distinction to the user is, by definition, forcing the user to think like a machine.

- Creative Suite http://helpx.adobe.com/creative-suite/kb/error-case-sensitiv...

- Steam https://support.steampowered.com/kb_article.php?ref=8601-RYP...

- Unity http://forum.unity3d.com/threads/fatal-error-case-sensitive-...

Mac apps not running on case sensitive filesystems is probably more common than not.

Sure, but he doesn't need to bitch about things just to bitch about things... it's not like case sensitivity is a problem for anything but poorly designed build systems.

So your Adobe example is flawed. They should be testing on case-sensitive volumes, but the vast majority of normal users don't want a file named README and readme in the same directory, and enforcing that invariant seems reasonable to me.

Which it does indeed, pretty badly. You would be hard pressed to find a worse FS still in use, excluding FAT, which will just never die.

Except the article doesn't contribute to the discussion and the quotes from Linus are unfortunately not newsworthy. Instead of a deep critique, perhaps pointing what it should learn from Btrfs and ZFS, he acuses Apple of not shipping a consumer case sensitive FS and criticizes its string and slash encoding, which although bad, are successfully abstracted even from most developers.

It then ends stating that Apple, like the weather, pays no attention to criticism. As empty an analysis as can be.