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

Re: representing file pathnames

Chuck Lever wrote:
> On Aug 9, 2012, at 2:46 PM, Howard Chu wrote:
>> Michael Ströder wrote:
>>> Chuck Lever wrote:
>>>> 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.

I see no reason why it should not be able to use NFS URLs and define the exact
usage of them for NFSv4. Maybe I'm overlooking something though.

Ciao, Michael.