1. 14
  1.  

  2. 24

    The title of this article is way overblown. Here’s an alternative summary:

    Previously, on HFS+, names were stored Unicode normalized under NFD. That worked fine in MacOS, but is tricky in OS X, because Unix says that file names/directory names are a series of arbitrary bytes that do not contain NUL–nothing more, nothing less. If you’ve ever had fights over Subversion v. Git v. Mercurial name mangling, that’s why that came up: even ignoring case folding, it was trivial to create file names on Linux/BSD that could not be losslessly round-tripped through macOS or Windows.

    APFS breaks with HFS+ tradition and goes with Unix tradition: while NFD is the preferred normalization format, there’s nothing guaranteeing that, and file names are ultimately nothing more than byte sequences that do not contain NUL. This is a behavioral change, but saying it’s “unusable with most non-English languages” is, in my opinion, incorrect. After all, this is the exact same situation Unixes have been under for decades, and it’s honestly been fine in practice.

    But beyond that, for people who do not work with command-line tooling, this should be a non-issue. The system frameworks, as noted in this article, will continue using NFD Unicode. The risk is with command-line utilities, which will now be able to losslessly preserve traditional Unix filenames. For me, as a developer, this is an improvement–and for most people, I suspect it won’t honestly make much of a difference.

    1. 8

      Wait, Apple made a change that makes git work better? I’m outraged! Oh, hold on, you say this makes cvs work better, too? Well, finally, it’s about damn time!