Linus Torvalds Expresses His Hatred For Case-Insensitive File-Systems : linux

[–] [email protected] 75 points 2 months ago (2 children)

I recall a case-insensitivity bug from the early days of Mac OS X.

There are three command-line utilities that are distributed as part of the Perl HTTP library: GET, HEAD, and POST. These are for performing the HTTP operations of those names from the command line.

But there's also a POSIX-standard utility for extracting the first few lines of a text file. It's called head.

I think you see where I'm going with this. HEAD and head are the same name in a case-insensitive filesystem such as the classic Mac filesystem. They are different names on a Unix-style filesystem.

Installing /usr/bin/HEAD from libwww-perl onto a Mac with the classic filesystem overwrote /usr/bin/head and broke various things.

[–] [email protected] 26 points 2 months ago (21 children)

Case insensitive is more intuitive and MUCH safer.

You do not want every Windows user to live in a world where Office.exe, office.exe, Offlce.exe and 0fflce.exe are all different files.

OSs and filesystems aren't built for programmers, they're built for grandmas. Programmers just happen to use them. It's much more sensible to give programmers a harder time fixing bugs and incompatibilities than it is to make the user experience even marginally worse.

I mean, all due respect for the guy, but that is an absolutely terrible opinion and I will die on this hill.

[–] [email protected] 56 points 2 months ago (1 children)

Your grandma will never type file names in shell, she'll use Open File dialog, where case sensitivity does not matter.

[–] [email protected] 19 points 2 months ago (1 children)

Hah. Second absolutely deadpan Average Familiarity instance in a Linux forum I have this week.

I mean, no offense to grandma. Plenty of grandmas are computer literate. But the idea of this hypothetical normie Windows user doing anything but double click on an icon (too slowly, with a bit too much pressure on the left mouse button, as if that made a difference, probably having single clicked to select first, just in case) is absurd.

File names are icon names first and foremost. File paths are a UI element to breadcrumb the location of the currently open file manager/explorer window unless proven otherwise.

And that is the right answer and how the whole thing should be designed.

[–] [email protected] 13 points 2 months ago

double click on an icon (too slowly, with a bit too much pressure on the left mouse button, as if that made a difference, probably having single clicked to select first, just in case

I do that.
I use KDE.
I am a programmer.

Also, I make directories with the correct capitalisations for the project names before going inside them and running git clone, which makes another directory in small letters.

Also, when I make header files matching class names, I capitalise them same as the class name. That messes up stuff for some others, sometimes. I like it.

[–] [email protected] 22 points 2 months ago (1 children)

OSs and filesystems aren't built for programmers, they're built for grandmas.

You're just flat out and completely wrong.

No grandma is typing out file URLs. This is not a point.
OSes literally do nothing useful on their own. Their explicit purpose is to allow developers to write applications for them for users to use.
Case insensitivity can be handled at the application level, there is no necessity to handle it at the OS level.
Case insensitivity isn't even clearly defined as Linus outlined, but you know what is clearly defined? Different character byte codes.

[–] [email protected] 6 points 2 months ago (1 children)

The entire issue is that gradmas don't type out filepaths.

When you're tying filenames case is easy, because a) you have to press something different, and b) typically terminal monospace fonts look very different in caps and non caps.

But in a GUI where you aren't typing the names out? For a human reading human text caps and non caps are interchangeable. So as the name of an icon case sensitivity is confusing and prone to human error.

I mean, it's that in typing, too, because it's a very easy typo to make and all sorts of mixed case choices can be hard to remember, but it's MORE confusing if you end up with just an icon with a name and the exact same icon with the exact same name just one character is a different case.

OSs don't do anything by themselves, but they come bundled with all sorts of standardize applications built on top of them. If case sensitivity is baked into the filesystem, it's baked into the filesystem. And absolutely no, you can't put it in at the application level. I mean, congratulations for finding the absolute worst of both worlds, but how would that even work? If I tell an app to use a file and there are two of them with different cases how would that play out? You can build it into indexing and search queries and so on when they will display more than one result (and that, by the way, is typically extra EXTRA confusing), but you can't possibly override the case sensitive filesystem.

Now, character byte codes are a different thing, and it's true that the gripe in this particular rant seems to be almost more focused into weird unicode quirks and the case sensitivity thing seems to be mostly a pet peeve he rolls into it, I suspect somewhat facetiously.

But still, that's for the OS, the filesystem and the applications to sort out. It's an edge case to handle and it can be sorted out via arbitrary convention regardless of whether you do case sensitivity for filenames. "Case insensitive means insensitive to other things, too" is not a given at all.

[–] [email protected] 10 points 2 months ago* (last edited 2 months ago) (10 children)

Now, character byte codes are a different thing, and it's true that the gripe in this particular rant seems to be almost more focused into weird unicode quirks and the case sensitivity thing seems to be mostly a pet peeve he rolls into it, I suspect somewhat facetiously.

No, it has nothing to do with "weird Unicode quirks".

It has everything to do with their being a universal standard for representing different characters, and the file system deciding to then apply its own random additional standard on top that arbitrarily decides some thing are probably the same as others.

This is just like Javascript's early ==, fuzzy equality choice. It was done to be helpful, but was a fuzzy system that doesn't cover enough edge cases to be implemented at that low of a level.

load more comments (10 replies)

[–] [email protected] 19 points 2 months ago* (last edited 2 months ago) (5 children)

Case insensitive is more intuitive

Are these the same filename?

ΑΓΑΘΉ.txt
αγαθή.txt

What about these?

MY-NOTES-ON-Δ.txt
μυ-notes-on-δ.txt

Databases have different case-insensitive collations - these control what letters are equivalent to each other. The fact that there's multiple options should tell you that there's no one-size-fits-all solution to case insensitivity.

This issue is only simple and obvious if you don't know enough about it.

[–] [email protected] 8 points 2 months ago (1 children)

I mean, cases in non-latin alphabets are cases as long as they function like cases, equivalences between alphabets are not cases, they're equivalences between alphabets and a different issue altogether. At least that'd be my starting point for implementation.

But you're misrepresenting my argument. I don't give a crap if it's simple and obvious to implement and it's not my claim that it is. If it's simple and obvious to the user it's still the right call, even if the implementation is complicated and has to deal with edge cases.

My last caveat there would be that nobody claimed that a one-size-fits-all is necessary. Ultimately you're not deciding the case sensitiveness of databases, just of one database, and that's the filesystem's naming rules. The rules are arbitrary and conventional. Short of raw "any character code will always be different from any other character code regardless of how visually similar or grammatically interchangeable the user-facing glyphs may be" any other solution is just as arbitrary as each other. You're always making a decision about it.

My contention is the decision shouldn't be based on what is comfortable or more straightforward to implement, debug or use for the OS developers, it should be what is more usable by the lowest common denominator GUI-only users. And that's case insensitive (but otherwise long and flexible) filenames.

[–] [email protected] 7 points 2 months ago* (last edited 2 months ago) (1 children)

But you're misrepresenting my argument.

Hardly, I'm directly addressing your statement that case insensitive is intuitive to users, grandmas or otherwise - I give examples where it's not initiative or obvious which filenames match. I didn't mention ease of implementation at all.

The principle of least surprise is an important UX consideration, and your idea of effectively introducing collation and localising which files conflict is just trading one problem for another set of problems and suprises (e.g. copying directories between drives with different settings).

load more comments (1 replies)

load more comments (4 replies)

load more comments (18 replies)

[–] [email protected] 10 points 2 months ago

Hey I have one of these case sensitive Mac OS X stories as well!

I gave it a try one time, and I found out the hard way some developers don't test everything in a case sensitive environment. I don't remember what specifically went wrong, but Adium, The instant messaging client, blew up because it couldn't find certain files on the local hard drive.

[–] [email protected] 61 points 2 months ago* (last edited 2 months ago) (1 children)

I prefer case sensitivity, the filesystem shouldn't do any magic like that. If someone types "file.txt", opening "File.TXT" would be convenient, but also misleading. Ignoring case is what autocompletion/search is for imo.

[–] [email protected] 30 points 2 months ago (2 children)

The best things is when the OS enforces magic onto the filesystem. Ntfs is case sensitive but windoze is not. So expect some real fun times if you use ntfs on other systems.

[–] [email protected] 29 points 2 months ago (1 children)

For real. It's a ton of fun when you have a Linux server presenting a SMB share and you get a folder called MyFolder and one called MYFOLDER. Take a guess about what happens in that situation. I guarantee it's different

load more comments (1 replies)

[–] [email protected] 45 points 2 months ago (2 children)

remember when windows could only handle 8 characters and longer names ended in ~1

[–] [email protected] 26 points 2 months ago

To be precise, longer names ending with ~1 are a backwards compatible fix for DOS programs introduced after Windows started supporting longer filenames.

load more comments (1 replies)

[–] [email protected] 31 points 2 months ago (2 children)

Utterly reasonable opinion. Case insensitive filesystems are just lazy programming.

[–] [email protected] 46 points 2 months ago (1 children)

Case insensitive file systems arent lazy, they're a programmer putting in a lot of effort to try and be helpful only to realize that their helpful system doesn't actually cover all the edge cases it needs to and thus just adds a whole extra layer of complication and annoyance to the project.

[–] [email protected] 6 points 2 months ago (1 children)

Hmmm. I doubt that, unless they were really bad programmers, downcasing (or upcasing) the file name in the file name accessors took much work, but I'll grant it's more than zero.

I'll retract the "lazy" comment.

[–] [email protected] 19 points 2 months ago (1 children)

That's because you're thinking in your tiny ASCII bubble. Switching case in Unicode is a hugely complex problem.

load more comments (1 replies)

[–] [email protected] 31 points 2 months ago (1 children)

Kind of the opposite. It takes more effort to make a filesystem case-insensitive. Binary comparison is the laziest approach. (Note that laziness is a virtue.)

I'm on the fence as to which is better. Putting backwards compatibility aside, there's a perfectly good case to be made for case-insensitivity being more intuitive to the human user.

Apple got into a strange position when marrying Mac OS (case-insensitive) and NeXTSTEP (case-sensitive). It used to be possible to install OS X on case-sensitive HFS+ but it was never very well supported and I think they axed it somewhere down the road.

[–] [email protected] 9 points 2 months ago* (last edited 2 months ago)

I can with very high confidence say that for the average computer user, case-insensitive is basically the only alternative. At least if you don't want IT and computer support around the world to start going postal.

As soon as someone is at least semi comfortable navigating a unix-style terminal and using a terminal based text editor to at least change config files, case-sensitive starts to become better. And often the more you get into programming, the more you get like Linus here and develop a hate.

[–] [email protected] 29 points 2 months ago (1 children)

What the hell phoronix, why are you using that cookie vendor that will sell your data to 46396 parties and no worries, you can stop it by deselecting each one of them! You can either accept or spend the day disabling this shit.

If that's how it's going to be, phoronix is done for me, sorry. I'd love to support your work even, but not with this

load more comments (1 replies)

[–] [email protected] 20 points 2 months ago (3 children)

Damn straight. I thought bcachefs was a modern filesystem? Why is it case insensitive? Huge red flag.

[–] [email protected] 20 points 2 months ago

Isn't bcache the one made by the solo dev who was causing all that drama trying to merge a bunch of crap during a freeze last year?

If so that explains quite a bit lmao

[–] [email protected] 11 points 2 months ago (1 children)

It isn't normally, but it, like e.g. Ext4, allows case insensitivity mostly for the sake of Wine.

[–] [email protected] 9 points 2 months ago (5 children)

But Wine could handle the case insensitivity though? NTFS is case sensitive.

load more comments (5 replies)

[–] [email protected] 7 points 2 months ago* (last edited 2 months ago)

Its' lead dev is also so full of himself, it's insufferable

[–] [email protected] 14 points 2 months ago (11 children)

Good for him. I hate case-sensitivity, and it's what keeps me going back to DOS & Windows. FILE, File, file, and FilE should all be the same thing at all times.

[–] [email protected] 23 points 2 months ago (14 children)

FILE, File, file, and FilE should all be the same thing

If these were truly the same thing, you should have not written them differently.

But you did.

[–] [email protected] 6 points 2 months ago (1 children)

Was this really supposed to be a clever point?

[–] [email protected] 6 points 2 months ago (1 children)

it's not "supposed". It just is.

load more comments (1 replies)

load more comments (13 replies)

[–] [email protected] 16 points 2 months ago

This is really a problem of human vs computer thinking.

F and f are two different characters, encoded differently. Ergo, File and file are different by raw bytes.

Some developers wish to make the interactions for the user more consistent and thus a case-insensitive filesystem is born. The problem is that this is such a low level place to make this decision.

A filesystem, as in the kernel level interactions for files, should be case-sensitive in that every character is a unique series of bits. But there’s nothing stopping a higher level api from helping users out. It would be sensible to have a case-insensitive desktop environment.

The low level functionality should remain intentional though.

[–] [email protected] 10 points 2 months ago* (last edited 2 months ago)

FILE, File, file, and FilE should all be the same thing at all times.

"Let's point many completely different combinations of characters at the same file"

sentences dreamed up by the utterly deranged /hj /lh

[–] [email protected] 9 points 2 months ago (3 children)

I was looking into this recently and I didn't know this but NTFS is actually designed by competent people and is fully case sensitive.

For backwards of course Microsoft had to make the file APIs case insensitive, but the actual filesystem is case sensitive.

Also, presumably because this is a real turn-off for developers there is actually an option in Windows to sort of make specific directories case sensitive. Wild right?

https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity

[–] [email protected] 7 points 2 months ago

Yeah, I think Windows actually handles it quite well, the actual filesystem has no notion of what the filenames are outside of basic "It's UTF-16", it's the OS filesystem layer that handles all the quirks.

Because that's what people seem to dismiss, there's no one standard notion of case folding. It depends on the locale you're using, and that shouldn't be built into the FS itself. The classic one was the German "long S", where "SS" should be case folded with "ß", except they changed it in 2024 so now they shouldn't match ("ß" becomes "ẞ" now), good luck updating your FS to support rules like that.

Now your shell? That's easy, you can just warn the user that a "matching" filename already exists and prompt them to change it, and you can vary those warnings based on the locale, and you can push out updates as easily as any other patch.

load more comments (2 replies)

[–] [email protected] 7 points 2 months ago* (last edited 2 months ago) (2 children)

"FILE, File, file, and FilE should all be the same thing at all times." - Sentences from the utterly deranged.

load more comments (2 replies)

load more comments (6 replies)

[–] [email protected] 13 points 2 months ago (3 children)

TIL case insensitive filesystems are still a thing actually in use.

Why lol

[–] [email protected] 11 points 2 months ago (1 children)

Windows. Probably.

[–] [email protected] 12 points 2 months ago (1 children)

Believe it or not, NTFS isn't, but Windows is to keep ye olde DOS compatibility lol.

load more comments (1 replies)

[–] [email protected] 6 points 2 months ago

I believe macOS's default partition is case-insensitive but not case-preserving. I remember having to check the HUnit (unit testing library for Haskell) in a special partition because darcs barfed on a file whose case changed.

I remember that the BeFS in BeOS was also case-preserving but not case-sensitive. Scot Hacker, the author of the BeOS Bible, relayed an explanation that resonated with him. (Bear in mind that this was pre-2000 and the computing landscape was much different. This was also the time that macOS was born in.)

The short of it is that it's for usability. The average person doesn't really differentiate between upper- and lowercase; at most, it's just aesthetics. If they want to find their resume, they don't care if it's spelled resume, Resume, RESUME, or even rEsUmE. Why should the computer require that they conform to a design decision that was made decades prior?

Since then, the world has changed again and the average user of today is even further isolated from the internals of a system. And what was a good idea in 1997 may not longer be relevant now.

load more comments (1 replies)

[–] [email protected] 11 points 2 months ago

Conversely: that two files that differ in name only by non-visible and humanly-impossible-to-detect details is an enormous user-experience fail.

[–] [email protected] 11 points 2 months ago

Such insensetivity!

[–] [email protected] 6 points 2 months ago (3 children)

What about case insensitive programming languages?

Im a python programmer so I'm used to it, but my coworkers are SAS programmers that is case insensitive and they keep getting errors when trying to write python because of that.

load more comments (3 replies)