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

From: Trond Myklebust <[email-masked]>
Date: Tue, 19 Oct 2010 17:25:10 -0400

Hi,

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.

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)?

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?

Cheers
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Oct 2010 16:53:31 -0500

>      2. The server may specify a 'pathname4' with a single component of

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.

> 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.

> 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
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Oct 2010 16:56:21 -0500

Well, a server could accept empty components, and treat them as if they
are not there.

What must not be allowed is objects with empty names.

---

From: <[email-masked]>
Date: Tue, 19 Oct 2010 21:08:54 -0400

> 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. 

Why do you presume that?

I guess it is the only way you can make representation 2 appear logical.

I just don't think that representation 2 is logical.  Representation 1
makes the most sense having more than one representation for the same
thing does not really make sense.

But we have a practical problem, in that some servers generate
representation 2 and it doesn't seem fair at this point to reject what
they are sending if we can figure out what was intended.  The spec
didn't tell them to do something else.

So I think it makes sense to say:

     you SHOULD send representation 1.
     you MAY send representation 2.
     you MUST NOT send a pathname4 with a zero-length component 
         unless it is an instance of representation 2.

     you MUST accept representation 1.
     you SHOULD accept representation 2.
     you MUST reject a pathname 4 with a zero-length component
         unless it is an instance of representation 2. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Trond Myklebust
Sent: Tuesday, October 19, 2010 5:25 PM
To: [email-masked]
Subject: [nfsv4] [RFD] How to interpret empty path components in
fs_locations/fs_locations_info

Hi,

Cheers
  Trond

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 21 Oct 2010 15:32:36 -0400

>          unless it is an instance of representation 2.

Agreed.

>      you SHOULD accept representation 2.

Agreed

>          unless it is an instance of representation 2. 

I'm not sure I agree with this. If a client is given a crazy pathname by
the server, through an fs_locations request, but it still manages to
make sense of it, then why shouldn't it make the attempt? The
alternative would be to tell the application 'EIO'...

Cheers
  Trond

---

From: <[email-masked]>
Date: Thu, 21 Oct 2010 22:07:26 -0400

> I'm not sure I agree with this. If a client is given a crazy 
> pathname by the server, through an fs_locations request, but 
> it still manages to make sense of it, then why shouldn't it 
> make the attempt? The alternative would be to tell the application 
> 'EIO'... 

Note that the third point which you agreed says you MUST NOT send
something like that.  If someone sends me something that the spec says
he MUST NOT, I feel that the best thing to do is to reject it.
Otherwise, you the spec has to decide what this thing that it has
defined as not valid means, and why bother doing that.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Thursday, October 21, 2010 3:33 PM
To: Noveck, David
Cc: [email-masked]
Subject: RE: [nfsv4] [RFD] How to interpret empty path components in

Agreed.

Agreed

Cheers
  Trond