Re: representing file pathnames
On Aug 9, 2012, at 2:46 PM, Howard Chu wrote:
Michael Ströder wrote:
> Chuck Lever wrote:
>> Can we represent the full range of the UTF-8 code set with a US-ASCII file
>> URL?
>
> Yes, of course just like HTTP URLs can contain non-ASCII chars in an
> URL-quoted form. You first encode to UTF-8 and then URL-quote. Decoding means
> URL-unquote and the decode UTF-8 to Unicode char entities.
OK, that makes sense.
>> We could also use an NFS URL, which would allow us to express
the server
>> hostname, a port number, and the pathname in a single string. But both the
>> hostname and pathname are enocded in US-ASCII, not UTF-8, and the NFS URL
>> format employs a fixed pathname separator character.
>
> That's what I would prefer. Think of file browsers which can open the NFS
> mount point just by clicking on it. Same encoding steps as with file URLs.
This seems the most obvious and natural solution (NFS URL). After all, you are
specifying an NFS resource...
I've looked more closely at this idea. While it's got some surface appeal, NFS
URLs (RFC 2224) don't specify a generic NFS resource. They specify a webDAV like
resource that can be accessed with NFS, called WebNFS (RFC 2054, RFC 20550), which gives
clients access via a so-called "public file handle," which is a degenerate NFS
FH.
WebNFS is defined only for legacy versions of NFS, not for NFSv4. Referrals are supported
only in NFSv4. In fact, section 4 of RFC 2224 specifies that clients try version 3 then
version 2. NFS version 4 is not discussed.
Thus, the form of an NFS URL might be rich enough, but the existing semantics are not
equivalent.
There may still be value, however, in understanding any issues around expressing a single
pathname string with a fixed separator character and how we can use that to express a list
of UTF-8 pathname components.
Otherwise I think we would have to specify a new NFS URL format to get what we need.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com