Re: [patch] mount.nfs: Add support for nfs://-URLs ...

[Chuck Lever <chuck.lever@oracle.com>]

On 12/10/24 7:13 AM, Cedric Blancher wrote:
> On Sun, 8 Dec 2024 at 23:12, NeilBrown <neilb@suse.de> 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