Conversely: that two files that differ in name only by non-visible and humanly-impossible-to-detect details is an enormous user-experience fail.
this post was submitted on 25 Apr 2025
273 points (97.6% liked)
Linux
7099 readers
784 users here now
A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
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.
TIL case insensitive filesystems are still a thing actually in use.
Why lol
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.
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.
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 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...
Such insensetivity!
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".
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.
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.
load more comments
(4 replies)
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.
load more comments
(41 replies)
view more: next ›