Conversely: that two files that differ in name only by non-visible and humanly-impossible-to-detect details is an enormous user-experience fail.
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
Yeah, I tried disabling my ad blocker to support them, but the page does not show ads even then and complains as if it were still active, and I think it is because I left Privacy Badger on. There is no way I am turning that off, so too bad for them!
Heck, I would even consider subscribing, but it looks like one first needs to create a forum account before one can even see the subscription price‽ What a very weird site…
TIL case insensitive filesystems are still a thing actually in use.
Why lol
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 evenrEsUmE. 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.
Because I’m a person not a robot. I don’t use ASCII codes to sort information, so why does my tool?
I disagree with most of his rant but this part is right
Dammit. Case sensitivity is a BUG. The fact that filesystem people still think it’s a feature, I cannot understand.
Windows. Probably.
Believe it or not, NTFS isn’t, but Windows is to keep ye olde DOS compatibility lol.
Mac’s APFS is like this too, to an extent. I don’t know the details but it’s also in that gray area.
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.
Ouch. Relying on case sensitivity is a lousy coding choice, anyway. No one is made better off by having a case change carry meaning.
Edit: Before anyone asks, I like case convention as a courtesy, too. But my code doesn’t rely on it.
Such insensetivity!
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, andPOST. 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.
HEADandheadare 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/HEADfromlibwww-perlonto a Mac with the classic filesystem overwrote/usr/bin/headand broke various things.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.
Your grandma will never type file names in shell, she’ll use Open File dialog, where case sensitivity does not matter.
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.
I don’t have Windows here to test, so I keep wondering, are all of these forms the same?
- facture-février.pdf
- FACTURE-FÉVRIER.PDF
- FACTURE-FEVRIER.PDF
On a NTFS drive on Windows with default settings the first two are the same, the third one is not.
Caps and non-caps are matched, accented/unaccented characters are not, which is probably what you’d expect.
Thanks. That is what I’d expect, and highlights the disconnect I saw in this comment chain: I think what some other folks were trying (less-than-artfully) to say is that there’s a difference between what one might expect case-insensitive means as a computer programmer, and what one might expect case-insensitive to mean in human language. All three of those should be the same filename in fr_FR locale, since some French speakers consider diacritical marks to be optional in upper case. While that might be an edge case, it does exist. English is even worse, with a number of diacritical marks that are completely optional, but may be used to aid legibility, e.g. café, naïve, coöperation. (Whether that quirk is obvious or not, or whether it outweighs any utility of case-insensitivity is not something that I have a strong opinion on, though.)
Whaaaat? You’re telling me someone in the Linux community chooses to be deliberately obscure based on a technicality no end user cares about in a patronizing, elitist manner?
Naah. Impossible.
The issue with the special characters for accent marks and diacritics is their importance fluctuates per language, so you have to keep them separate unless you want to make different rules per locale instead of per character.
They do it the other way for number formatting and that’s already a mess. If you’ve ever tried to work with spreadsheets across locale formats it’s absolutely bonkers. Excel outright changes the separators in formulas.
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.
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.
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.
Arbitrary is the word.
Arbitrary means you can implement it however you want. The limits to it are by convention. There is no need to go any further than case insensitive filenames. At all. Rolling case insensitive filenames into the same issue is entirely an attempt to make a case against a pet peeve for unrelated reasons.
You want it to handle the edge cases? Have it handle the edge cases. You want to restrict it to the minimum feature just for alphabet characters? Do that.
But you do NOT give up on the functionality or user experience because of the edge cases. You don’t design a user interface (and that’s what a OS with a GUI is, ultimately) for consistency or code elegance, you design it for usability. Everything else works around that.
I can feel this conversation slipping towards the black hole that is the argument about the mainstream readiness of Linux and I think we should make a suicide pact to not go there, but man, is it starting to form a narrative and am I finding it hard to avoid it.
There is no need to go any further than case insensitive filenames. At all. Rolling case insensitive filenames into the same issue is entirely an attempt to make a case against a pet peeve for unrelated reasons.
This is literally just the same issue. I cannot see what two issues you are separating this into.
All of this stems from case insensitive file names.
But you do NOT give up on the functionality or user experience because of the edge cases. You don’t design a user interface (and that’s what a OS with a GUI is, ultimately) for consistency or code elegance, you design it for usability. Everything else works around that.
The OS is not the GUI. Every GUI you see in the OS is an application running on top of the actual OS.
The OS should not arbitrarily decide that some characters are the same as others, it should respect the unified standards for what bytes represent what characters. Unless there is an internationally agreed upon standard for EXACTLY what case insensitive means for every character byte code, then you are building a flawed system that will ruin the user experience when massive bugs and stability issues come up because you didn’t actually plan out your system properly to cover edge cases.
You know, as Linus is pointing out given his multi decade history of running Linux.
No, hold on, this is not about the OS.
This is about whether the filesystem in the OS supports case insensitive names.
That determines whether the GUI supports case insensitive names down the line, so the choices made by the filesystem and by the OS support of the filesystem must be done with the usability of the GUI in mind.
So absolutely yes, the OS should decide that some characters are the same as others, not arbitrarily but because the characters are hard to read distinctly by humans and that is the first consideration.
Or hey, we can go back to making all filenames all caps. That works, too and fully solves the problem.
remember when windows could only handle 8 characters and longer names ended in ~1
No because that’s not a thing in the way you’ve described it
To be precise, longer names ending with ~1 are a backwards compatible fix for DOS programs introduced after Windows started supporting longer filenames.
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.
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.
Why shouldn’t I be able to have the files mare.png (a photo of a horse) and MarE.png (a photo taken on a vacation in March, fifth in the series after MarA, MarB, MarC, and MarD)?
Or rainsley (a text file, no extension, with notes about a story I’m writing) and Rainsley (a directory with art of the same character the file is named after)?
Do I strictly need to be able to do these things? No, of course not. But the file system is more flexible and functional if I am able to.
Because humans don’t actually work that way
Also on user-oriented operating systems you can have spaces in file names without issue
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
“FILE, File, file, and FilE should all be the same thing at all times.” - Sentences from the utterly deranged.
Linus agrees, from the article
Dammit. Case sensitivity is a BUG. The fact that filesystem people still think it’s a feature, I cannot understand.
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.
What an absolutely fucking obtuse troll comment. Go back to your bridge.
Was this really supposed to be a clever point?
it’s not “supposed”. It just is.
It just is stupid. It only sounds like a clever retort if you don’t think about it.
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.TXTandFiLe.tXt, they’ll haveReportMay.docxandREportMay.docxor whatever.And yeah, that includes me. I don’t want case-sensitivity for that reason alone. Thanks, but no thanks.
I prefer computers do what I tell them to rather than what it thinks I meant to tell it to. If I screw up, why isn’t it on me to fix it? And why aren’t you proofing data entry before accepting it?
This is the first time in my entire life I’ve heard a human being refer to “naming a file” as “data entry” that requires “proofing”. Are you secretly a machine?
How is it not data, usually key data, no less? It requires a unique path/filename combination, has to be human readable, is entered by a user. Not traditionally what one would think of as data entry, but is data that is entered and referenced. And unless you only use the recent view for finding files, knowing that the name is entered as intended seems rather important.
And perhaps I am also secretly a machine.
Definitely huu-man
You’re arguing it needs to be human readable and entered by humans but also arguing that case sensitivity – something that is not a thing amongst us humans – is good.
So? Numbers need to be human readable and entered by humans, too, and I’ve seen discussions about the proper pronunciation of 1.32. There are a number of ways that appear equally useful, but there is a convention that has been applied to remove ambiguity. And that convention is ignored in areas where other issues are more important. That convention is no more natural than writing itself, yet most people beyond a basic level of numeracy (and, perhaps, English fluency) know it. Moreover, filenames, just like numbers, need to be computer readable, as well, and conventions have been applied. Some of those conventions were constrained by the capabilities of computers of the time, just like with dates.
And people are very much case-aware. IF THEY WERENT, WHY ARE ALL CAPS COMMENTS INTERPRETED DIFFERENTLY?
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.
when I save a file and then search to recall it, it should not matter what case it’s in
Whatever you use to search can just be case insensitive, which is how most file browsers work on Linux.
Then why should it allow me to save different expressions of the same meaning ever? If it’s going to let me search for it case-insensitive, just head the matter off at the pass and save it that way. Either that, or automatically create link files for every case permutation to the same folder as soon as the file exists.
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.
Why? They did it right…
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.
That’s because you’re thinking in your tiny ASCII bubble. Switching case in Unicode is a hugely complex problem.
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
ISO 8601? A man of culture I see.
It’s the only sane dating system.
It’s so funny to me that humans use numbers that are big to small, but some people are that dates should be small to big. Maybe other languages do it differently. But UK folks saying day month year is better while writing the individual number big to small is so wacky to me. Today is 2025-04-27. If they said it like “7 and 20, April, 5 and 20 two thousand” it might make more sense, but no, it’s “27 April 2025”.
Damn straight. I thought bcachefs was a modern filesystem? Why is it case insensitive? Huge red flag.
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.
It does, but having case insensitivity in the file system can get you better performance.
How would that happen?
If you’re running Wine on a case-sensitive file system, and you it tries to open a file, it would first try to open a file whose case matches exactly. But if it doesn’t find one, it would then need to list all the files in the directory, normalize their case, and go through them all to see if there is a file with the given name but in a different case. That can take some time if there is a lot of files in the directory.
But if you’re on a case-insensitive filesystem, the FS can keep case-normalized names of all files on disk, so you can do a case-insensitive open just as fast as you can do a case-sensitive open.
BTW, another application that can benefit from this is Samba, since SMB is case-insensitive.
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.
Trying to rename a file to use the correct capitalization in a git repository on my Windows laptop for work was tricky. Or maybe it was subversion. Actually I think it was subversion. Either way it was a weird little puzzle for the day.
