[Date Prev][Date Next] [Chronological] [Thread] [Top]

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