On Wed, 11 Dec 2024 at 05:26, NeilBrown <neilb@xxxxxxx> wrote: > > 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. Gentoo-based ClipOS&RED FLAG Linux certainly support that, first one for iso8859-16 mapping, and the second for GB18030. I don't know if this is in mainline or not. In either case mapping to local encoding is required, or as Roland's comment indicates a mount syscall parameter to indicate the encoding of the export path string. > > 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? For SMB certainly yes. For NFSv3 certainly yes too, for example if the NFS server runs on a filesystem with a different encoding than the client. Might be even a subset or superset of the encoding used by the other side, e.g. server uses Level GBK/5, but client only Level GBK/3. Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
