Case sensitive OSes like Linux don’t mix well with case insensitive file systems.
Take files under /boot/EFI (FAT). Packaging systems fall down on such — two RPMs can have different cases of the same filename and the package manager won’t know. They’ll just subtly overwrite each others file depending on installation/upgrade order.
(And why should the package manager have to care about the case sensitivity of the underlying file system for each managed file?)
It's some kind of game theory game. If software and data is being transferred between Windows and Unix system it will be rare for Unix software to break on Windows, yet, Windows allow carelessness about capitalization which breaks when you round trip to Linux. Embrace, Extend, Exterminate, etc.
Windows can be configured to have whole-volume case-sensitivity with NTFS, or even directory-specific case-sensitivity.
However, case-sensitivity is user-unfriendly. README.DOCX, Readme.docx, ReAdMe.DocX -- which document did they really want? When Jane Doe calls and tells John Doe to open the "readme" document, which one does she mean?
Case-insensitive helpers around a case-sensitive filenames are the best of both worlds. I don't want hello.txt to BE the same as Hello.txt, I just want to find it without using a capital letter. Thanks to this thread I just discovered <code>bind -s 'set completion-ignore-case on'</code> for bash which is going to make my life as someone who frequently switches between WSL2 and Windows cmd more pleasant.
If I ask the question of "would it be perverse to deliberately write code to systematically depending on case?" I think about coding 11001000 as 'AAaaAaaa' or instead of a random identifier written like 798951cb-9fa4-4ca6-9a36-6b098a9cbd25 you write likewise in more or less
I grew to like case insensitive dbms like SQLServer as it makes me think less about casing when I write queries, but always wondered if that comes at cost of performance!
Collation in a database determines case sensitivity in MSSQL. If the collation has "cs", it's case-sensitive. If it has "ci", it is case-insensitive.
Collation is configurable at the server level, but usually one goes for a _CI_ collation there (not much reason for master to be _CS_). Each user database can have it's own collation/case-sensitivity.
Case sensitive OSes like Linux don’t mix well with case insensitive file systems.
Take files under /boot/EFI (FAT). Packaging systems fall down on such — two RPMs can have different cases of the same filename and the package manager won’t know. They’ll just subtly overwrite each others file depending on installation/upgrade order.
(And why should the package manager have to care about the case sensitivity of the underlying file system for each managed file?)
It's some kind of game theory game. If software and data is being transferred between Windows and Unix system it will be rare for Unix software to break on Windows, yet, Windows allow carelessness about capitalization which breaks when you round trip to Linux. Embrace, Extend, Exterminate, etc.
Windows can be configured to have whole-volume case-sensitivity with NTFS, or even directory-specific case-sensitivity.
However, case-sensitivity is user-unfriendly. README.DOCX, Readme.docx, ReAdMe.DocX -- which document did they really want? When Jane Doe calls and tells John Doe to open the "readme" document, which one does she mean?
Case-insensitive helpers around a case-sensitive filenames are the best of both worlds. I don't want hello.txt to BE the same as Hello.txt, I just want to find it without using a capital letter. Thanks to this thread I just discovered <code>bind -s 'set completion-ignore-case on'</code> for bash which is going to make my life as someone who frequently switches between WSL2 and Windows cmd more pleasant.
Having both hello.txt and Hello.txt is bad design in the first place no matter how you view it.
"bad design" - It is not design just result of Unicode rules.
Mind you:
naïve.txt
naïve.txt
can both exist, because:
ï vs ï
0xC3AF vs 0x69CC88
is not same.
Linux does sane (secure) thing - does not care. If bytes are different - name is different.
Windows and mac don't solve this anyway.
Having only one of Α.txt, A.txt, a.txt is not, and was not, а option.
If I ask the question of "would it be perverse to deliberately write code to systematically depending on case?" I think about coding 11001000 as 'AAaaAaaa' or instead of a random identifier written like 798951cb-9fa4-4ca6-9a36-6b098a9cbd25 you write likewise in more or less
https://en.wikipedia.org/wiki/Ascii85
that last would be clever but unwise to write to the filesystem
.ToUpper() .ToLower() I say.
Yes, you can find exceptions to the point of case-sensitivity is user-unfriendly. For developers, sure. For end users? It's always unfriendly.
Though there's nothing wrong with file names with GUIDs; SharePoint does it all the time ;-)
macOS also is case insensitive
Likewise Linus also considers HFS+ a piece of shit filesystem: https://archive.is/R5eWO
Recent news of Linux also considering removing the drivers for it: https://www.phoronix.com/news/Linux-2025-Sad-State-HFS
macOS hasn't used HFS+ as the default FS in what 10+ years?
APFS is case-insensitive by default. It can be formatted to be case-sensitive. I don't think you can change sensitivity on the fly like Windows.
No, I did re-install MacOS once and enabled case-sensitivity filesystem and photoshop stopped working.
No what? That’s a 3rd party application. MacOS runs just fine with a case-sensitive file system.
I grew to like case insensitive dbms like SQLServer as it makes me think less about casing when I write queries, but always wondered if that comes at cost of performance!
Collation in a database determines case sensitivity in MSSQL. If the collation has "cs", it's case-sensitive. If it has "ci", it is case-insensitive.
Collation is configurable at the server level, but usually one goes for a _CI_ collation there (not much reason for master to be _CS_). Each user database can have it's own collation/case-sensitivity.