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.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.
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.
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.
That –at best– gives you the same performance.
EDIT: Ok, I misunderstood – you meant the performance of “case insensitive in kernel” vs. “case insensitive in userspace”. I get your point now.
No? Either the application implements its own case-insensitive index, or you’ll have strictly worse performance than an implementation in the file system. The application would have to make multiple syscalls (which have a fixed overhead).
Its’ lead dev is also so full of himself, it’s insufferable
TIL case insensitive filesystems are still a thing actually in use.
Why lol
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.
Such insensetivity!
Conversely: that two files that differ in name only by non-visible and humanly-impossible-to-detect details is an enormous user-experience fail.
