Subject: RE: Should PUTPUBFH and PUTROOTFH check that fh is a dir

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 19 Nov 2002 12:21:59 -0800

Tom Haynes wrote:
> [David Robinson wrote:] 
> > Carl Burnett wrote:
> > > It seems that it would be a good idea for PUTPUBFH and PUTROOTFH to check 
> > > that the provided filehandle represents a directory . If not, then these 
> > > ops would return NFS4ERR_NOTDIR. The spec currently does not show these as 
> > > error returns for these operations.
> > > 
> > > What do people think?
> > 
> > In many common NFS server solutions it is possible to export just a
> > single file, not a directory.  The old SunOS 4.x diskless swap
> > files used this feature. Would this interpretation force a
> > server that wanted to export just a single file to also export its
> > parent directory as well?
> > 
> > 	-David
> > 
> 
> In the case of PUTROOTFH, you cannot export a single file - you need 
> to provide a root of a pseudo-fs from the spec.  This root need
> not be the parent of the single file, indeed it would be more flexible
> to build a pseudo-directory chain from the top of the fs.

Right.  The server has flexibility in how to present what is exported
as an externally visible namespace.  The pseudo-fs gives you that
flexibility.  The only restriction is that the root directory of the
pseudo-fs be a directory, and it's the server's responsibility to
make sure that is the case, so a NOTDIR error can't arise.

> As for the PUTPUBFH, yes it can be a FH to a file and not a
> directory, at least as the spec states:
> 
>    Unlike the ROOT filehandle, the PUBLIC filehandle may be bound 
>    or represent an arbitrary filesystem object at the server.

> Most implementations may chose to map the PUTPUBFH to the
> PUTROOTFH, but assuming that it is the PUTROOTFH violates the
> spec.

The spec is inconsistent on this point.  Section 4.1.2, which you
quote above also says,

     However, it is up to the administrative software at the 
     server and the policies of the server administrator to define 
     the binding of the PUBLIC filehandle and server filesystem 
     object.  The client may not make any assumptions about this 
     binding.

So that part of the spec says it can a file, a symlink, a named
attribute directory, a named attribute itself ...

However, if you go to 14.2.31, the section on PUTPUBFH, under
DESCRIPTION, you find:

     Replaces the current filehandle with the filehandle that 
     represents the public filehandle of the server's name space.  
     This filehandle may be different from the "root" filehandle 
     which may be associated with some other directory on the server. 

Note "Some other *directory*" (emphasis added).  That sure sounds 
like the spec here is assuming that the public fh is directory.

Further in this section it says:

     The public filehandle and the root filehandle (represented by the
     PUTROOTFH operation) should be equivalent.  If the public and root
     filehandles are not equivalent, then the public filehandle MUST be
     a descendant of the root filehandle.

So it seems that since the the server MUST make the pubfh either the same
or a descendent of the root fh, the client is justified in assuming that
one of those conditions holds, contradicting section 4.1.2, which says "The 
client may not make *any* assumptions" (emphasis added), although I
suppose the spec could deny clients the right to make assumptions that
the spec itself makes.

One way for clients to reconcile these two is simply never to use
PUTPUBFH.  That way you don't need to make any assumptions about what
PUTPUBFH returns, even though the spec does.  That works for me :-)
Servers can simply obey the "should" (it isn't a "SHOULD") and make
everything simple.  If all clients followed that approach it would mean 
that we would drop PUTPUBFH when we go to Draft Standard.

Do any clients out there actually use PUTPUBFH?  The spec indicates it
is to be used for some sort of WebNFS compatibility.  It references a
bunch of RFC's that I haven't read. (Maybe someday).  The thing I don't
understand is that if the spec recommends rootfh == pubfh, then it is
assuming that that is reasonable WebNFS compatibility approach, in which
case, there is no need for a separate PUTPUBFH.

> Also, assuming it is a directory also violates the spec as written.

At least partly.

Anyway back to Carl's question.  If it is valid for pubfh to be a file
(I'm kind of doubtful on that), then there should be no error.  If it
isn't valid, the server should make sure that it is a directory, most
likely by making the same as the rootfh.  Again, no error.

---

From: Carl Burnett <[email-masked]>
Date: Tue, 19 Nov 2002 15:52:05 -0600

Spencer's answer clears it up for me. Its really a property of the server, 
not the client. Therefore the error (.._NOTDIR) does not really apply. I 
should have concluded that on my own, if I had just thought a little more 
about the operation. Thanks for the interesting discussions anyway.

Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

Spencer Shepler <[email-masked]>
11/19/2002 04:06 PM

        To:     Carl Burnett/Austin/IBM@IBMUS
        cc:     [email-masked]
        Subject:        Re: Should PUTPUBFH and PUTROOTFH check that fh is a dir

These two operations do not take a parameter/filehandle and therefore
there should be no concern about checking of a filehandle.

It may not be perfectly clear but the expectation is that the server
will provide a filehandle that is a directory as the current filehandle
or result of these two operations.  That is the current assumption.

Carl Burnett wrote:
> Carl
> Carl Burnett
> AIX Kernel Architecture - Distributed File Systems
> (512) 838-8498, TL 678-8498
> (please reply to [email-masked])