6 ms·

And don’t you dare changing it unless you like random bugs

• deleted 4d ago
  [deleted]
• applfanboysbgon 4d ago
  Sell me on this. Why would you want to change it? What good can actually come of allowing foo and Foo to coexist in the same directory?
  • ErroneousBosh 4d ago
    They are completely different words. Why should they be used to mean the same thing?
  • retrac 4d ago
    Practically? Quite a few codebases from *nix systems rely on the case sensitivity. To do a successful git clone you need a file system that handles both Makefile and makefile, or whatever. I ran into it more than once back in the day when I used Mac OS X as my primary OS. More generally -- case sensitivity is a conceptual nightmare in the Unicode era. Should Cyrillic or Greek be case-insensitive as well? Etc. Do you really want the full complexity of Unicode string handling in your file system? I would suggest treating file names like raw bytes. On modern Linux, anything but NUL is valid.
  • LoganDark 4d ago
    It can be nice to checkout some Git repositories that have this. It can also be nice to catch miscapitalizations of filename imports when those would fail on Linux, etc. One of my past workplaces actually had that problem, they mis-cased imports and the product failed to build on Linux. Nobody caught it because they all used macOS or Windows, I was the first to try WSL (this was before I switched back to Mac) You would be asking for a world of hurt to put your root filesystem in a case-sensitive volume though. All sorts of software and applications have silently relied on case-insensitivity for decades. You can sometimes fix it on a case-by-case basis, but sometimes you can't, and it's also annoying for it to happen in the first place. Better to have a separate case-sensitive volume just for the stuff you want to be case-sensitive.