On Sun, 8 Dec 2024 at 23:12, NeilBrown <neilb@xxxxxxx> wrote: > > + > > + /* > > + * |pnu.uctx->path| is in UTF-8, but we need the data > > + * in the current local locale's encoding, as mount(2) > > + * does not have something like a |MS_UTF8_SPEC| flag > > + * to indicate that the input path is in UTF-8, > > + * independently of the current locale > > + */ > > I don't understand this comment at all. > mount(2) doesn't care about locale (as far as I know). The "source" is > simply a string of bytes that it is up to the filesystem to interpret. > NFS will always interpret it as utf8. So no conversion is needed. Not all versions of NFS use UTF-8. For example if you have NFSv3 and the server runs ISO8859-16 (French), then the filenames are encoded using ISO8859-16, and the NFS client is assumed to use ISO8859-16 too. mount(2) has options to do filename encoding conversion NFSv4 is an improvement compared to NFSv3 because it uses UTF-8 on the wire, but if you use the (ANSSI/Clip-OS) nls=/iocharset= mount option you can enable filename encoding conversion there. Traditionally it is assumed that the admin runs its shell in the locale (implies filesystem encoding) used to do the mount(2), hence the iconv() to make sure there is no encoding mismatch. Finally: Not everyone and everything will use English (we frog eaters are proud of our language!) or UTF8, and it will remain that way for the foreseeable future. Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
