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

>The above clearly says that for clientB the filehandle for the file
> after the REMOVE operation MAY be valid.

As I read it, it MAY be either valid or invalid and this applies to
validity as perceived by any client.

> The clientB just removed the file, so it should not be surprised
> the filename (obtained in step 2) is no longer valid.

He shouldn't, but if he was a stickler for unix semantics, he would have a
problem.

> What is unclear to me is clientA.  Is it okay for the server to
> 'forget' the filehandle even for clientA?

It is allowed by the spec.

> 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.

True but people have been OK with this for two reasons:

   1. Most clients will implement NFSv3 sillyrename which is alluded to in
   the paragraph above the bulltets you quote.  Interestingly, it is a
   "should" rather than a "SHOULD", since interoperability is not affected.
   2. In the case of other clients, NFS users may have have been bringing
   expectations formed on the basis of experiences with NFSv3, and from an
   NFSv3 perspective, this server behavior is unexceptionable.

A possible extension to NFSv4.2 could provide an attribute to allow the
client to determine how the server dealt with this issue.

> 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,

I'm don't think you can be sure of this, since

   1. In speaking of the directory entry it only says "SHOULD NOT"
   2. The text doesn't say explicitly that processing should stop at this
   point, with an error returned.
   3. there seems to be no text at all regarding continued access to the
   file by existing opens in the DENY case.  This may need some sort of
   correction but I'm not sure at this point exactly what sort of correction
   we could put in, given the need to be compatible with all existing
   implementations.

> which sounds like overkill.

Not exactly:

   1. It prevents stuff you don't want to prevent
   2. It is not guaranteed to prevent what you really want to prevent.

> Am I overlooking something?

I think you are overlooking sillyrename.

In your example either or both of A and B might by implementing
silllyrename and it isn't clear how things would work if both A and B did.
:-(

I think it would help if we considered this issue in historical context.
Making NFSv4 stateful was a wrenching change and it is not surprising if we
have adapted to that change incompletely.  Some of the IESG commentary
about RFC3530 expressed reserve or uncertainty (although no actual
objection) about making this change, saying essentially "Well if you guys
*really* want to do this, OK".

On Fri, Dec 9, 2016 at 5:25 PM, Marcel Telka <marcel@telka.sk> wrote:

> 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:   marcel@telka.sk  |
> |                homepage: http://telka.sk/ |
> |                jabber:   marcel@jabber.sk |
> +-------------------------------------------+
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>