On 12/9/24 10:15 AM, Takeshi Nishimura wrote:
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.
Dude, settle yourself. That comment is out of line and you are reading
something into my remark that is not there. Let's stick with technical
comments.
The central problem, as you've laid out below, is that copy-paste isn't
working for you. If copy-paste is a problem for NFS, it is a problem
elsewhere too, thus it should be addressed where it can do the most
good. Neil and I are both pointing out that there might be a better
place to address this issue; we are not saying it's not consequential.
In order to make a clear rationale for NFS URLs based on copy-paste,
the below details are important to include. But we also need to
understand why NFS (which has no notion of command line copy-paste)
needs to tackle this problem.
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.
Our point is: why not fix copy-paste, then? Please provide rationale
for why this issue should be addressed by piecemeal changes to every
system utility rather than addressing the copy-paste mechanism.
If the issue has already been addressed in many other system utilities
in this way, then please include examples in the patch description.
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?
--
Chuck Lever
