Re: [I18ndir] I-D on filesystem I18N

[Nico Williams <[e-mail]>]

On Wed, Jul 08, 2020 at 12:23:53PM -0400, John R Levine wrote:
> So long as we make it clear what kind of advice it is, and we acknowledge
> the issues in migrating from what they do now to UTF-8 nirvana, that could
> be somewhat useful.

Right!  Thank you for seeing that.  This work sure can't hurt.

Migration is tough of course, but for _new_ filesystems it is a
non-issue (unless the intent is to restore existing contents that needs
migration).  Stopping the rot is often the first step towards repairing
it.

Two schemes are described in my I-D: the HFS+ scheme (normalize on
create and lookup) and the ZFS scheme (form-insensitive/preserving).
(As you can see, there is nothing terribly original in this I-D...)

The former is by far the simplest to retrofit onto existing filesystem
code that doesn't index directory contents.  Conversely, the latter is
equally easy to retrofit into filesystems that do index directory
contents.

The latter yields superior user experience and interoperability, but the
former would be good enough if it normalized to NFC (sadly, Apple went
with NFD, but others could choose to use NFC).

Those two schemes were arrived at by Apple and Sun engineers between 2
and 1.5 decades ago, respectively.  To my knowledge, in all that time no
better approach has been found.

We should document this and take the opportunity to make small
improvements, such as mapping U+2011 to U+002D and such.  In the worst
case, it will do as much good as the NFSv4 spec's I18N provisions
(none), though also no harm.  In the best case it will help make all
sorts of filesystems better.

Lastly, I believe this approach has wider applicability, thus
documenting it may help in areas other than filesystems.

Nico
--