Subject: proposed text for issue06 (share_access == 0?)

From: Mike Eisler <[email-masked]>
Date: Thu, 29 Aug 2002 11:57:41 -0700

The original post for this issue and followup thread starts here 

    Regarding,

      access and deny fields are as follows:
   
      const OPEN4_SHARE_ACCESS_READ   = 0x00000001;
      const OPEN4_SHARE_ACCESS_WRITE  = 0x00000002;
      const OPEN4_SHARE_ACCESS_BOTH   = 0x00000003;
   
   Since these are constants and not enums, is there
   an implication that that if zero and not one of the
   _ACCESS_ constants are passed to OPEN that a file
   can be opened with neither read nor write access? I
   vaguely recall someone telling me that in Windows this
   was possible; if so, presumably the purpose is would be
   to merely deny open access to other potential openers.

Need to clarify the semantics of an access mode == 0.

-----------------

Since there appears to have been no discussion of this issue,
I will assume that we have concensus that an access mode of zero
is illegal.  Also, draft-leach-cifs-v1-spec-02.txt doesn't
mention a way to open a file without some explicity form of
access. Therefore, I will assume that an open access value of
zero is illegal.

Also, there is already text that says:

     For SHARE reservations, the client must specify a value for access
     that is one of READ, WRITE, or BOTH.  For deny, the client must
     specify one of NONE, READ, WRITE, or BOTH.  If the client fails to
     do this, the server must return NFS4ERR_INVAL.

Although, OPEN does not list INVAL as an valid error, yet.

Suggested text changes follow:

CHANGE (in 8.9.  Share Reservations)

                if ((request.access & file_state.deny)) ||
                      (request.deny & file_state.access))
                              return (NFS4ERR_DENIED)

TO:

                if (request.access == 0) 
                   return (NFS4ERR_INVAL)

                else
		   if ((request.access & file_state.deny)) ||
		         (request.deny & file_state.access))
			         return (NFS4ERR_DENIED)

CHANGE (in 14.2.16.  Operation 18: OPEN - Open a Regular File)

     For SHARE reservations, the client must specify a value for access
     that is one of READ, WRITE, or BOTH.  For deny, the client must
     specify one of NONE, READ, WRITE, or BOTH.  If the client fails to
     do this, the server must return NFS4ERR_INVAL.

TO:

     For SHARE reservations, the client must specify a value for share_access
     that is one of READ, WRITE, or BOTH.  For share_deny, the client must
     specify one of NONE, READ, WRITE, or BOTH.  If the client fails to
     do this, the server must return NFS4ERR_INVAL.

CHANGE (in 14.2.16.  Operation 18: OPEN - Open a Regular File):

     NFS4ERR_GRACE
     NFS4ERR_IO

TO:

     NFS4ERR_GRACE
     NFS4ERR_INVAL
     NFS4ERR_IO

CHANGE (in 14.2.19.  Operation 21: OPEN_DOWNGRADE - Reduce Open File Access
):

     The access and deny bits specified in this operation replace the
     current ones for the specified open file.  The access and deny bits
     specified must be exactly equal to the union of the access and deny
     bits specified for some subset of the OPEN's in effect for current
     openowner on the current file.  If that constraint is not
     respected, the error NFS4ERR_INVAL should be returned.  Since
     access and deny bits are subsets of those already granted, it is
     not possible for this request to be denied because of conflicting
     share reservations.

TO:

     The share_access and share_deny bits specified in this operation replace the
     current ones for the specified open file.  The share_access and share_deny bits
     specified must be exactly equal to the union of the share_access and share_deny
     bits specified for some subset of the OPEN's in effect for current
     openowner on the current file.  If that constraint is not
     respected, the error NFS4ERR_INVAL should be returned.  Since
     share_access and share_deny bits are subsets of those already granted, it is
     not possible for this request to be denied because of conflicting
     share reservations.

CHANGE (in 14.2.19.  Operation 21: OPEN_DOWNGRADE - Reduce Open File Access):