[nfsv4] RFC 7530: Filehandle of opened file after the REMOVE

[Marcel Telka <[e-mail]>]

Hi,

I'm not sure I understand RFC 7530 properly.  Here is the scenario I'm not sure
about:

1. clientA opens a file named with OPEN4_SHARE_DENY_NONE.
2. clientB opens the (same) file with OPEN4_SHARE_DENY_NONE.
3. clientB removes the file using the REMOVE operation.

In section 16.26.5. there is this:

   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 the last CLOSE of the file, the
      server MAY continue to allow access to the file via its
      filehandle.

The above clearly says that for clientB the filehandle for the file after the
REMOVE operation MAY be valid.  The clientB just removed the file, so it should
not be surprised the filename (obtained in step 2) is no longer valid.

What is unclear to me is clientA.  Is it okay for the server to 'forget' the
filehandle even for clientA?  If the filehandle won't be valid for clientA
(after the REMOVE by clientB), then clientA might lost the access to the file
anytime, and it have no easy chance to prevent that (and no way to recover from
that).  This sounds unfortunate and it breaks the traditional unix semantics:
the file is there while I hold it opened.  The only way to make sure the file
is available until the final CLOSE seems to be to open the file with
OPEN4_SHARE_DENY_WRITE or OPEN4_SHARE_DENY_BOTH, which sounds like overkill.

Am I overlooking something?


Thank you.

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   [e-mail]  |
|                homepage: http://telka.sk/ |
|                jabber:   [e-mail] |
+-------------------------------------------+