On Sun, Dec 8, 2024 at 4:58 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On 12/7/24 10:29 PM, NeilBrown wrote: > > On Sun, 08 Dec 2024, Chuck Lever wrote: > >> On 12/7/24 3:53 PM, NeilBrown wrote: > >>> On Sat, 07 Dec 2024, Chuck Lever wrote: > >>>> Hi Roland, thanks for posting. > >>>> > >>>> Here are some initial review comments to get the ball rolling. > >>>> > >>>> > >>>> On 12/6/24 5:54 AM, Roland Mainz wrote: > >>>>> Hi! > >>>>> > >>>>> ---- > >>>>> > >>>>> Below (and also available at https://nrubsig.kpaste.net/b37) is a > >>>>> patch which adds support for nfs://-URLs in mount.nfs4, as alternative > >>>>> to the traditional hostname:/path+-o port=<tcp-port> notation. > >>>>> > >>>>> * Main advantages are: > >>>>> - Single-line notation with the familiar URL syntax, which includes > >>>>> hostname, path *AND* TCP port number (last one is a common generator > >>>>> of *PAIN* with ISPs) in ONE string > >>>>> - Support for non-ASCII mount points, e.g. paths with CJKV (Chinese, > >>>> > >>>> s/mount points/export paths > >>>> > >>>> (When/if you need to repost, you should move this introductory text into > >>>> a cover letter.) > >>>> > >>>> > >>>>> Japanese, ...) characters, which is typically a big problem if you try > >>>>> to transfer such mount point information across email/chat/clipboard > >>>>> etc., which tends to mangle such characters to death (e.g. > >>>>> transliteration, adding of ZWSP or just '?'). > >>>>> - URL parameters are supported, providing support for future extensions > >>>> > >>>> IMO, any support for URL parameters should be dropped from this > >>>> patch and then added later when we know what the parameters look > >>>> like. Generally, we avoid adding extra code until we have actual > >>>> use cases. Keeps things simple and reduces technical debt and dead > >>>> code. > >>>> > >>>> > >>>>> * Notes: > >>>>> - Similar support for nfs://-URLs exists in other NFSv4.* > >>>>> implementations, including Illumos, Windows ms-nfs41-client, > >>>>> sahlberg/libnfs, ... > >>>> > >>>> The key here is that this proposal is implementing a /standard/ > >>>> (RFC 2224). > >>> > >>> Actually it isn't. You have already discussed the pub/root filehandle > >>> difference. > >> > >> RFC 2224 specifies both. Pub vs. root filehandles are discussed > >> there, along with how standard NFS URLs describe either situation. > >> > >> > >>> The RFC doesn't know about v4. The RFC explicitly isn't a > >>> standard. > >> > >> RFC 7532 contains the NFSv4 bits. RFC 2224 is not a Normative > >> standard, like all early NFS-related RFCs, but it is a > >> specification that other implementations cleave to. RFC 7532 > >> /is/ a Normative standard. > > > > The usage in RFC 7532 is certainly more convincing than 2224. > > > >> > >> > >>> So I wonder if this is the right approach to solve the need. > >>> > >>> What is the needed? > >>> Part of it seems to be non-ascii host names. Shouldn't we fix that for > >>> the existing syntax? What are the barriers? > >> > >> Both non-ASCII hostnames (iDNA) and export paths can contain > >> components with non-ASCII characters. > > > > But they cannot contain non-Unicode characters, so UTF-8 should be > > sufficient. > > > >> > >> The issue is how to specify certain code points when the client's > >> locale might not support them. Using a URL seems to be the mechanism > >> chosen by several other NFS implementations to deal with this problem. > > > > If locale-mismatch is a problem, it isn't clear to me that "mount.nfs" > > is the place to solve it. > > > > The problem is presented as: > > > > to transfer such mount point information across email/chat/clipboard > > etc., which tends to mangle such characters to death (e.g. > > transliteration, adding of ZWSP or just '?'). > > > > So it sounds like the problem is copy/paste. I doubt that NFS addresses > > are the only things that can get corrupted. > > Maybe a more generic tool would be appropriate. > > I agree. The cited copy/paste use case is pretty weak. What a bold statement. Classic English-only user. Have you ever worked in a mixed language environment? Used VMware with Japanese Windows, and Japanese MAC OSX, and used clipboard between all these virtual machines? For example if you use MS File Explorer, and use "Copy Address", not "Copy Address As Text"? You'll find Unicode zero width space markers (class ZWSP), characters which are not displayed, to mark the begin and end of a Win32 object file name. Just Linux clipboard doesn't know about that little detail, worse, in UTF8 locales the characters are still invisible, because they use zero terminal cells (wcwidth() returns 0 for ZWSP characters!) you are literally screwed over. So copy in Windows, paste in Linux, paths will not work, unless you paste in the Linux terminal, then select© in the terminal the SAME path, and then paste it again. That works because it eliminates the ZWSP. BIDI (Bidirectional Text Layout) also uses such markers, depending on application. Shitty .NET apps for example. Finally, there is CTL, Complex Text Layout, for languages like Hindi (just 600 million people speak that as first or second language, so no need to care about them). Wanna hear what inter-OS clipboard usage does to such paths? -- Internationalization&localization dev / 大阪大学 Takeshi Nishimura <takeshi.nishimura.linux@xxxxxxxxx>
