On Tue, 10 Dec 2024, 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. > 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. I cannot find any evidence that nfs supports iocharset- or nls= Other filesystems do: fat, isofs, jfs, smb ntfs3 and others. But not NFS. nfs-utils doesn't appear to have any support either. So I think that the string you pass on the mount command line, or in /etc/fstab, will be passed unchanged over-the-wire to mountd (For NFSv3) or passed to the kernel and thence to nfsd (for NFSv4). Do you have evidence to prove otherwise? i.e. can you demonstrate a case where changing the LOCALE causes a mount command that previously worked to stop working? Thanks, NeilBrown
