Subject: [nfsv4] NFS4ERR_FILE_OPEN

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Dec 2007 05:58:45 -0500

RFC3530 specified that this error could be returned by LINK, REMOVE, and
RENAME.  The only other reference to this error in the spec was the
following line:

>           NFS4ERR_FILE_OPEN       = 10046,/* open file blocks op.
*/

I'm trying to make the v4.1 spec a little clearer on this issue and I
want to make sure what I'm doing is consistent with people's
understanding.

For LINK and RENAME, I'm simply going to say something like:

   A server may disallow this operation when the corresponding file
   is open, or open with particular modes specified.  When the operation
   is disallowed on this basis, the error NFS4ERR_FILE_OPEN is returned.

Then there needs some text about delegation recall in this connection.

For REMOVE, we have the following current text to deal with:

   o  The server SHOULD NOT delete the file's directory entry if the
      file was opened with OPEN4_SHARE_DENY_WRITE or
      OPEN4_SHARE_DENY_BOTH.

The odd thing here is it says that the server SHOULD NOT delete the
file's directory entry but it doesn't say what it should do.  My
assumption would be that it would return an error in this case and the
one that makes most sense is NFS4ERR_FILE_OPEN.  Does anyone think
something else whould be done?

   o  If the file was not opened with OPEN4_SHARE_DENY_WRITE or
      OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's
      directory entry.  However, until last CLOSE of the file, the
      server MAY continue to allow access to the file via its
      filehandle.

I assume that a server may decide to reject RENAME if the file is open
at all and return NFS4ERR_FILE_OPEN if it makes this choice.

Other opinions?

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