I definitely prefer case-senstive. I didn't realize that MacOS had switched to case-INsensitve at some point. So the following drove me crazy for several minutes:

$ ls -l /usr/local/bin/virtualbox

-rwxr-xr-x 1 root wheel 77 Oct 2 2015 /usr/local/bin/virtualbox*

$ ls /usr/local/bin | grep virtualbox

<nothing, WTF??>

$ ls /usr/local/bin | grep -i virtualbox

VirtualBox*

My coworker uses MacOS, I use Linux. Several times, changing the case of a directory or file caused the MacOS to mess up the local git repo so badly that we had to blow it away and refetch from remote.

At least the Mac Finder allows changing the case of a filename. Windows File Explorer simply refuses. I change the case of the file name, add a random character, save the file name. Then edit the file name again, remove the random character, save the file name. It's needlessly annoying.

I think case-INsensitive makes more sense for software developers, since there are many instances where things like "string.h" is not the same as "String.h". But for normal people, case-INsensitve may be more useful. However, even for normal users, I think there are situations where "bob.html" (a noun) is different from "Bob.html" (a person).

>At least the Mac Finder allows changing the case of a filename. Windows File Explorer simply refuses

Just tested on Windows 10 and this is definitely not true. I could have sworn you could always do it, but my memory of Windows < 10 is foggy. And you can also do the renaming from any console app (cmd, powershell, etc), FYI.

NTFS is case-preserving, but case-insensitive. That, IMO is a good balance. When they were first making NT with the posix subsystem, I suppose they found that the number of cases where two files that only differed in case lived in the same directory were small enough to not matter.

I personally don't think case-sensitivity in file names adds anything useful.

I swear that my Windows 10 File Explorer had this problem.

Here is a user complaint about this problem from Nov 2019: https://answers.microsoft.com/en-us/windows/forum/all/cant-r...

Here's another post from May 2018, explicitly mentioning Windows 10: https://answers.microsoft.com/en-us/windows/forum/all/why-ca...

But I checked again on my own Windows 10 machine (Windows 10 Pro, Version 2004, build 19041.450) and holy shit, it now works. It must have been fixed in a recent Window 10 update.

If you enabled the posix subsystem NTFS became case sensitive as well, although most API passed a flag to disable that for Win32 file calls.

It’s interesting that Microsoft effectively added the reverse feature to NTFS [1] to support per-directory case sensitive files to be more compatible with Linux.

[1] https://www.tiraniddo.dev/2019/02/ntfs-case-sensitivity-on-w...

Mac has been (at least by default) case-insensitive for a very long time, back to the original HFS at least, and probably its predecessor MFS too, though I'm not sure on that one.

I thought that I had used Macs with HFS+ filesystem that was case-sensitive a long time ago, but I'm not 100% sure anymore.

You might've. It's a format-time option and has been for as long as I've used OS X.

Interesting in the sense of "May you live in interesting times", yes.

It introduces near-endless complications, especially in the face of Unicode, and one should think thoroughly about it before implementing it, as you can read in Torvalds' initial reaction linked elsewhere in this discussion. But the way they did it seems relatively sane to me, with an easy way to compartmentalize it to, e.g., a Steam directory.

That comment section is pretty interesting to read...

I don't really have a use case for that feature right now. But that doesn't mean others don't have a use-case for this feature.

As the comment section reads, most feel entitled to NOT HAVE this convenience feature implemented for others, because they do not need it. It feels like a cognitive bias, but does it have a name, besides "get off my lawn?"

Because it can be rather frustrating to deal with problems owing to case insensitivity on systems that allow it.

How? If your program asks the OS for a handle for “data.db” and it returns one for “Data.db”, does it matter? If your program asked for “data.db”, why should your program care that the only match was for “Data.db”, so it got that?

If there are two with these names:

    İdata.db
    Idata.db

which one should be opened when you ask for "idata.db"?

What about if only the first file exists, and you open for writing a file called "Idata.db"? Should it overwrite the first file, or create the second?

If it should overwrite the first file, unpacking an archive that contains both will result in a missing file.

What about these two, you might feel differently about because they are visually distinct:

    ßdata.db
    SSDATA.DB

These are not theoretical questions. On some OSes, the answer changes depending on ephemeral language settings that the current program may not be aware of or expecting.

In some environments, the answer doesn't change but doesn't match what happens in other environments. E.g. many systems implement ASCII case-folding only, others implement more characters but not Unicode, others implement all of Unicode.

Inevitably a program somewhere will break because this wasn't anticipated.

A backup using an archiver will not restore what was there before, and something that worked before the backup will behave differently after the restore.

A script (such as a build script) may inadvertantly create both files when run with one language setting, then break when the language setting is changed, even thought the script doesn't have anything to do with languages.

Your carefully written novel, that has chapter files with names you thought were distinct, will have missing chapters when you copy it across to another system. You discover this months later when you start working again on the novel, long after destroying the original system you thought you had copied from.