Subject: RE: Questions about FH ops (GETFH, SAVEFH, PUTFH, RESTOREFH)

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 2 Sep 1999 09:17:38 -0700

> > I have questions about the ops to support the current 
> > file handle concept.
> 
> my take on how it should be:
> 
> > 
> > First, what happens if I haven't set up a current file
> > handle?  Is there a default or is this an error?
> 
> error.

Make sense to me.

> 
> > 
> > The fact that GETFH has no error listed besides
> > SERVERFAULT (i.e no INVAL) seems to indicate that there
> > is a default, since there is no way to indicate that
> > a bare GETFH (i.e. without a preceeding PUTFH) would be 
> > invalid.  Have I missed where the default is explained?  
> > The obvious default is the public file handle but I 
> > couldn't see anywhere where the spec says that.
> 
> The spec should say INVAL.

If INVAL is the right thing for GETFH without a current
file handle, then you would have to make it INVAL for any
op that require a current file handle that didn't have one.
INVAL is used for so may things, that it might be better
to create a new error NOFH for this situation.

> 
> > 
> > Another question has to do with the error list for 
> > SAVEFH.  I can't make sense of a lot of the
> > errors that are there.  I would argue that the error
> > list should be the same as GETFH.  I'm assuming that
> > GETFH does not have errors like FHEXPIRED, BADHANDLE,
> > WRONGSEC, etc. since the error should have been 
> > generated when the handle was established rather than
> > at GETFH.  If so, SAVEFH is precisely in the same
> > position.  GETFH and SAVEFH both move a current 
> > handle somewhere else and I don't see why they should
> > differ in whether or not they check that handle for
> > validity.  You could argue that because of the lack
> > of atomicity for COMPOUND a handle can expire or go
> > stale between ops and so it might become invalid
> > before the SAVEFH but the same applies to GETFH. 
> > Also, I don't understand what INVAL is for in the 
> > error list for SAVEFH.
> 
> If there isn't an fh to save, then INVAL is appropriate.
> 
> 
> > 
> > I have a similar question about the error lists for
> > PUTFH and RESTOREFH.  They are similar in that they
> > both set the current file handle.  With RESTOREFH,
> > the file handle in question must have been valid at
> > one time so there is a possibility that some types
> > of errors that PUTFH returns might not be possible
> > for RESTOREFH, but (except for the case of INVAL),
> > the reverse should not be possible.  If RESTOREFH
> > checks for FHEXPIRED, for example, so should PUTFH.
> > If the idea is that this needs to be checked when
> > the handle is used, as opposed to set, the the same
> > thing should apply to RESTOREFH.
> 
> Agreed.

If we agree that the error list for GETFH and SAVEFH
should be the same and those for PUTFH and RESTOREFH 
should be aligned as well, which way should it be done.
Should GETFH and SAVEFH check the handles and return
errors like WRONGSEC, FHEXPIRED, STALE or should that
be the job of ops which actually generate the handles?
Should RESTOREFH and PUTFH check the handles and 
return these errors or is it up to the ops which use
the handles to check them?  Maybe the spec should
allow GETFH, PUTFH, SAVEFH, RESTOREFH to make these
checks (by putting the errors in the error lists for
each of these ops), but not require the checks at that
point.  The only checks that have to be made are when 
the handle is actually used.  Does that sound reasonable?

This means that if I do:

     PUTFH (some totally invalid handle)
     GETFH

I may get BADHANDLE on the PUTFH, or on the GETFH, or it
may work without error.

By totally invalid I mean somethng that the server doesn't 
recognize but fits within the maximum handle length.

By the way what error should be returned if the handle length
is longer than allowed by the protocol?

---

From: Mike Eisler <[email-masked]>
Date: Thu, 2 Sep 1999 09:31:31 -0700 (PDT)

> to create a new error NOFH for this situation.

point.

> Maybe the spec should

this sounds reasonable.

> is longer than allowed by the protocol?

That is an RPC level error because it is something that gets detected in the
XDR decoding phase. The RPOC respond thus has MSG_ACCEPTED, followed by a
status of GARBAGA_ARGS. It does mean the client loses results of any
previously xecuted operations, but the client asked for it.

	-mre