On 12/10/24 7:13 AM, Cedric Blancher wrote:
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.
I'm still trying to understand the usefulness of supporting NFSv3 as
well. I understand that your usage requirement is only NFSv4.
However, does your comment mean that there might be some cases where
a client administrator might want to mount with NFSv3 using non-ASCII
characters (of any flavor) in the export path?
I'm also wondering about non-ASCII characters in the server hostname.
That does not depend on which NFS version is in play.
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.
I'll repeat: none of us are denigrating languages or usages here. We're
attempting to clarify the problem statement and refine the use cases.
--
Chuck Lever
