Re: [nfsv4] [RFD] How to interpret empty path components in fs_locations/fs_locations_info

[Nicolas Williams <[e-mail]>]

On Tue, Oct 19, 2010 at 05:25:10PM -0400, Trond Myklebust wrote:
> An issue was raised in the fedfs concall last week concerning how to
> represent the root directory in fs_locations/fs_locations_info.
> 
> As near as the group on the call could determine, there are 2 possible
> representations, neither of which appear to be explicitly forbidden by
> the spec:
> 
>      1. The server may specify a 'pathname4' entry with no components
>      2. The server may specify a 'pathname4' with a single component of
>         length 0.

I believe only (1) makes sense.  The root path has no components.  We
happen to write that as "/" in Unix-ish systems, but that's just because
"" would be rather confusable, whereas a single '/' is not.

> The following question then arose: if we allow representations of type
> 2. above, then presumably we must also allow for the fact that the
> server may embed zero-length components anywhere in the 'pathname4'
> array. We assume that the interpretation would then be the same as a
> POSIX path of the form /a/b/////c (i.e. the path should be interpreted
> as equivalent to /a/b/c)?

POSIX requires that /a/b/////c be the same as /a/b/c.  IIRC POSIX does
not require that /a, //a, and ///a all be the same -- it allows special
semantics for double slashes at the root of a path (IIRC this was for an
Appolo Domain feature) -- but we have no need for this.

If a POSIX client's user could never write a path like /a/b/////c with
actual empty components, then it'd be bad to allow such paths to exist.
Therefore servers must not allow them.  Which in turn makes (2) suspect,
though not outright wrong -- we need a convention, and in a pinch (2)
would do.

But if we can't allow empty components in paths with more than one
component, why not simply reserve all empty components and be done?
Then (1) is clearly the best choice.

> The question we'd like to put to the list is therefore whether or not
> clients should be required to deal with this, or whether the spec should
> be amended to discourage (or even forbid) servers from using this kind
> of representation for a path?

Servers which allow for empty components make impossible for POSIX
clients to get at filesystem objects with such paths.  That is what I'd
consider a Bad Thing.  Unless there exist major OSes which do allow
empty components, then I think empty components must be disallowed.

Q: Can any OS with a hierarchical filesystem structure have empty path
components?

POSIX doesn't allow it.  I don't think Windows allows it (as with Appolo
Domain, a leading double [back]slash denotes a UNC).  I doubt MacOS X
allows it either.  If no major OS allows it then there's no reason to
allow NFSv4 servers to allow it.  Even if there were a major OS that
allows empty components, the spec should at least describe issues
relating to them and say they are at least NOT RECOMMENDED if not
outright MUST NOT.

Nico
--