5 ms·

Moreover, I'd be nervous about the fact that filenames on Windows tend to be case insensitive.

by orra 22d ago

LoganDark 22d ago
macOS has a case-insensitive filesystem by default too.
- tobyhinloopen 22d ago
  And don’t you dare changing it unless you like random bugs
  - applfanboysbgon 22d 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?
    - LoganDark 22d 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.
    - retrac 22d 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.
      - IsTom 22d ago
        > anything but NUL is valid. And slash/!
    - ErroneousBosh 22d ago
      They are completely different words. Why should they be used to mean the same thing?
    - hn993302 22d ago
      Sometimes you download stuff that relies on case sensitivity. Anyone who's dealt with this probably has a sensitive RW DMG lying around for this reason. But macOS FSes default to case-insensitive, so random issues come up if you make your root sensitive (famously in Adobe software). Damned if you do or don't. Another weird thing in macOS: $ mkdir Cased $ cd cased $ pwd /Users/me/Downloads/cased $ cd ../Cased && pwd /Users/me/Downloads/Cased So yeah I wish the FS defaulted to sensitive, even though I never rely on that. Not its job to normalize names.
      - rcyeh 21d ago
        TIL that MacOS `pwd` has `-P` and `-L` options. -L Display the logical current working directory. -P Display the physical current working directory (all symbolic links resolved). If no options are specified, the -L option is assumed. In your example, using `-P` will show `Cased`.
        jech 19d ago
        > TIL that MacOS `pwd` has `-P` and `-L` options. Interestingly, it wasn't designed to deal with case, but to select whether to resolve symbolic links: $ cd /tmp $ mkdir a $ ln -s a b $ cd b $ pwd && pwd -P /tmp/b /tmp/a
        ButlerianJihad 19d ago
        In Bash and many modern POSIX shells, `pwd` is a builtin, not to mention an environment variable ${PWD}, but the POSIX system should also provide an external command, such as `/bin/pwd` that would operate on the filesystem, rather than semantically tracking your shell activity. https://manpages.ubuntu.com/manpages/stonking/man1/pwd.1.html https://manpages.ubuntu.com/manpages/stonking/man1/pwd.1.htm...
    - tobyhinloopen 21d ago
      Well, so you can base84 encode your filenames for example. (Jk) My main concern is the loose matching that comes with it where you can refer to any file or folder using any case without issue
    - dwedge 21d ago
      Mostly consistency in knowing that Foo will become foo. This is a problem when it comes to (for example) supporting devs on Windows working on a codebase with prod on Linux. The database dbCustomer would be renamed dbcustomer on Windows. There are workarounds, and containerization is a better idea, but you asked why you might want this.
  - deleted 22d ago
    [deleted]
ncruces 22d ago
I think the idea is that it being case preserving is sufficient to allow decrypting the filenames. And I guess it relies on the 31 (32?) bit blocks, to make colisions unlikely for short filenames.
- jasomill 22d ago
  This is true, but I'm not sure if I trust users to preserve case in case-insensitive filenames when copying files around, possibly at some point passing through something like a web server that may apply case normalization. Sort of like timestamps on files, they're handy for things like synchronization, but I hesitate before relying on them as a primary source of truth for anything mission critical.

Moreover, I'd be nervous about the fact that filenames on Windows tend to be case insensitive.

by orra 22d ago

Moreover, I'd be nervous about the fact that filenames on Windows tend to be case insensitive.

LoganDark 22d ago

macOS has a case-insensitive filesystem by default too.

tobyhinloopen 22d ago
And don’t you dare changing it unless you like random bugs
- applfanboysbgon 22d 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?
  - LoganDark 22d 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.
  - retrac 22d 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.
    - IsTom 22d ago
      > anything but NUL is valid. And slash/!
  - ErroneousBosh 22d ago
    They are completely different words. Why should they be used to mean the same thing?
  - hn993302 22d ago
    Sometimes you download stuff that relies on case sensitivity. Anyone who's dealt with this probably has a sensitive RW DMG lying around for this reason. But macOS FSes default to case-insensitive, so random issues come up if you make your root sensitive (famously in Adobe software). Damned if you do or don't. Another weird thing in macOS: $ mkdir Cased $ cd cased $ pwd /Users/me/Downloads/cased $ cd ../Cased && pwd /Users/me/Downloads/Cased So yeah I wish the FS defaulted to sensitive, even though I never rely on that. Not its job to normalize names.
    - rcyeh 21d ago
      TIL that MacOS `pwd` has `-P` and `-L` options. -L Display the logical current working directory. -P Display the physical current working directory (all symbolic links resolved). If no options are specified, the -L option is assumed. In your example, using `-P` will show `Cased`.
      - jech 19d ago
        > TIL that MacOS `pwd` has `-P` and `-L` options. Interestingly, it wasn't designed to deal with case, but to select whether to resolve symbolic links: $ cd /tmp $ mkdir a $ ln -s a b $ cd b $ pwd && pwd -P /tmp/b /tmp/a
      - ButlerianJihad 19d ago
        In Bash and many modern POSIX shells, `pwd` is a builtin, not to mention an environment variable ${PWD}, but the POSIX system should also provide an external command, such as `/bin/pwd` that would operate on the filesystem, rather than semantically tracking your shell activity. https://manpages.ubuntu.com/manpages/stonking/man1/pwd.1.html https://manpages.ubuntu.com/manpages/stonking/man1/pwd.1.htm...
  - tobyhinloopen 21d ago
    Well, so you can base84 encode your filenames for example. (Jk) My main concern is the loose matching that comes with it where you can refer to any file or folder using any case without issue
  - dwedge 21d ago
    Mostly consistency in knowing that Foo will become foo. This is a problem when it comes to (for example) supporting devs on Windows working on a codebase with prod on Linux. The database dbCustomer would be renamed dbcustomer on Windows. There are workarounds, and containerization is a better idea, but you asked why you might want this.
- deleted 22d ago
  [deleted]

ncruces 22d ago

I think the idea is that it being case preserving is sufficient to allow decrypting the filenames. And I guess it relies on the 31 (32?) bit blocks, to make colisions unlikely for short filenames.

jasomill 22d ago
This is true, but I'm not sure if I trust users to preserve case in case-insensitive filenames when copying files around, possibly at some point passing through something like a web server that may apply case normalization. Sort of like timestamps on files, they're handy for things like synchronization, but I hesitate before relying on them as a primary source of truth for anything mission critical.