On Fri, 20 Dec 2024, Cedric Blancher wrote: > 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. When I said "can you demonstrate" what I really meant was "will you please demonstrate for us". i.e. could you show us a mount command that works, but when you change LANG (or whatever) to choose a different locale, it doesn't work. Show us the command and the result in both cases include explicit setting of the LOCALE in each case. Add "-v" so we can see some of what is happening "under the hood". As the charset you will be using will not be unicode/utf-8 it might be tricky to reliably copy/paste the interaction into an email. Maybe copy/paste it into a file, check that the file contains the correct bytes, then attached that file to an email. It's not that I don't believe you. It is that fine details can sometimes have outsized importance and I want to have as much visibility into what is actually happening as possible. Thanks, NeilBrown
