4 ms·

One of Linus's main points is that this is a layer problem. Who cares if things get normalized in your Finder dialogs or other UX elements? But if something is

One of Linus's main points is that this is a layer problem. Who cares if things get normalized in your Finder dialogs or other UX elements? But if something is being programmatically done to the filesystem itself (ie, by git via a write) it should do what is advertised -- write some bits. It seems wrong that the filesystem itself should be concerned with normalizing filenames or flipping bits of any kind.

eridius 14y ago
It's not a layer problem. The fundamental problem is Linux is geared towards servers and HFS+ is geared towards consumers. On a server, it makes sense that whatever filename your program tries to write out is preserved perfectly. On a consumer-facing OS that's a terrible idea. Having mis-normalized filenames can cause all sorts of confusion. The most obvious is having two filenames that are grapheme-for-grapheme identical, but differ in the normalization of their characters. Less obvious is how to deal with situations where the user types a filename to open and their typed normalization differs from the actual normalization of the file on disk? Unless the filesystem itself performs the renormalization, there's no sane way to deal with this situation besides iterating over the directory and renormalizing each filename in the hopes of finding a match.
- mbell 14y ago
  I don't follow, looking at the number of files on my laptop right now a very, very small percentage of them are intended for my interaction. The vast majority are intended purely for interaction by programs / the system. That tells me the file system should handle what is best for that case and my interaction should be proxied by another program that makes the file system fit for my consumption, e.g. Finder.
  - eridius 14y ago
    Of all the files on my system, the only ones that even hit the normalization issue are explicitly meant for human interaction. OS files typically aren't named using non-ASCII characters.
    - mbell 14y ago
      That is exactly why they are a special case that should be handled by the file manager, not the file system.
      - eridius 14y ago
        You seem to be deliberately ignoring the fact that they cannot be handled by a layer on top of the filesystem without introducing all sorts of weird behavior and severe inefficiencies.

eridius 14y ago

It's not a layer problem. The fundamental problem is Linux is geared towards servers and HFS+ is geared towards consumers. On a server, it makes sense that whatever filename your program tries to write out is preserved perfectly. On a consumer-facing OS that's a terrible idea. Having mis-normalized filenames can cause all sorts of confusion. The most obvious is having two filenames that are grapheme-for-grapheme identical, but differ in the normalization of their characters. Less obvious is how to deal with situations where the user types a filename to open and their typed normalization differs from the actual normalization of the file on disk? Unless the filesystem itself performs the renormalization, there's no sane way to deal with this situation besides iterating over the directory and renormalizing each filename in the hopes of finding a match.

mbell 14y ago
I don't follow, looking at the number of files on my laptop right now a very, very small percentage of them are intended for my interaction. The vast majority are intended purely for interaction by programs / the system. That tells me the file system should handle what is best for that case and my interaction should be proxied by another program that makes the file system fit for my consumption, e.g. Finder.
- eridius 14y ago
  Of all the files on my system, the only ones that even hit the normalization issue are explicitly meant for human interaction. OS files typically aren't named using non-ASCII characters.
  - mbell 14y ago
    That is exactly why they are a special case that should be handled by the file manager, not the file system.
    - eridius 14y ago
      You seem to be deliberately ignoring the fact that they cannot be handled by a layer on top of the filesystem without introducing all sorts of weird behavior and severe inefficiencies.