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

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

Though I use a case-insensitive filesystem (APFS), I name all files lowercase with underscores and no spaces. Dates get hyphens. Example for purchase receipt to a show I'm about to attend: bloody_beetroots_2025-03-28.pdf

Such insensetivity!

remember when windows could only handle 8 characters and longer names ended in ~1
- To be precise, longer names ending with ~1 are a backwards compatible fix for DOS programs introduced after Windows started supporting longer filenames.

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

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.
- 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.
- 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.
  
  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.
  
  So every time grandma picks a file name she needs to specify the locale?
  What a stupid hill to die on.
  
  Your grandma will never type file names in shell, she'll use Open File dialog, where case sensitivity does not matter.
  
  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.
  
  But if someone creates a file called HEAD, should it overwrite a file called head?
  That shouldn't matter to the "nontechnical" end-user at all. To the nontechnical user, even the abstraction of "creating a file" has largely gone away. You create a document, and changes you make to it are automatically persisted to storage, either local or cloud.
  Only the technical command-line user cares about whether /usr/bin/HEAD and /usr/bin/head are the same path. And only in a specific circumstance — such as the early days of Mac OS X, where the Macintosh and Unix cultures collided — could the bug that I described emerge.

Damn straight. I thought bcachefs was a modern filesystem? Why is it case insensitive? Huge red flag.
- 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
- It isn't normally, but it, like e.g. Ext4, allows case insensitivity mostly for the sake of Wine.
  
  But Wine could handle the case insensitivity though? NTFS is case sensitive.
- Its' lead dev is also so full of himself, it's insufferable

Utterly reasonable opinion. Case insensitive filesystems are just lazy programming.
- 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.
  
  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.
- 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.
  
  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.

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.
- "FILE, File, file, and FilE should all be the same thing at all times." - Sentences from the utterly deranged.
- 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.
  
  Was this really supposed to be a clever point?
  
  you should have not written them differently.
  But you did.
  Remember that 99% of the time that's gonna be because of a typo for 99% users. They won't have File.txt, FILE.TXT and FiLe.tXt, they'll have ReportMay.docx and REportMay.docx or whatever.
  And yeah, that includes me. I don't want case-sensitivity for that reason alone. Thanks, but no thanks.
  
  I did, because they're different ways of expressing the same meaning. They all mean (apologies for borrowing mathematical notation for linguistic applications) |file|. I don't care what the expression of a thing is, I care about meaning. And as a result, when I save a file and then search to recall it, it should not matter what case it's in - only for the meaning to match. The state of my shift or capslock should be totally immaterial.
- 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.
- 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
  
  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.
  
  Ah, one more reason for me to despise NTFS.
- Couldn't agree more. I literally can not think of a single scenario where case sensitive file names would be anything but an annoyance.
- 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
- somehow you remInded me of the BIG-small archItecture.
  
  BlG-small?