Subject: RE: two questions on new .x

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 17 Oct 2001 11:22:10 -0700

As I read RFC3010, RENEW was like this (i.e having a stateid
but not requiring a current filehandle) so I already have
support for that in my stateid checking routine.

So now this no longer applies to RENEW (because it has a
clientid instead), but we have OPEN_CONFIRM taking its
place.  It appears that there is a Conservation of
Exceptions law active here.

-----Original Message-----
From: Kendrick M. Smith [mailto:[email-masked]]
Sent: Wednesday, October 17, 2001 1:49 PM
To: [email-masked]
Subject: two questions on new .x

1. The new OPEN_CONFIRM uses a stateid as its argument instead of a
verifier.  However, the OPEN response still includes the verifier,
which is no longer used anywhere.

2. OPEN_CONFIRM now uses a stateid in its argument.  All the other
operations which use stateids in their arguments (CLOSE, LOCK, LOCKU,
OPEN_DOWNGRADE, READ, WRITE) require the current filehandle to be
set to the object associated with the operation.  Is the new OPEN_CONFIRM
also subject to this requirement?  I see no reason why OPEN_CONFIRM
should be subject to this requirement, but I never saw any reason why
the other operations should be either, so I'm just asking in the
interest of consistency.  I became motivated to ask this question when I
went to implement the new OPEN_CONFIRM on my server and noticed that I
couldn't use the "generic" stateid checking function called by
CLOSE, LOCK, etc. since that function checked for agreement with the
current filehandle (although it would be easy enough to add a
DONT_CHECK_FILEHANDLE flag, of course...)

- k