Subject: RE: [nfsv4] NFS4ERR_FILE_OPEN

From: "Peter Varga" <[email-masked]>
Date: Fri, 14 Dec 2007 10:21:52 -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.

Good.

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

I suspect this text was an attempt to allow for Windows semantics with
respect to deletion of opened files. I would consider removing this text
completely because it is not representative of Windows' behavior, where
you _can_ delete a file that is already open with SHARE_DENY_WRITE.
Windows has a separate share mode, essentially OPEN4_SHARE_DENY_DELETE,
and also has a corresponding DELETE access right for opening a file.
Only if an application specifies SHARE_DENY_DELETE will an attempt to
open a file with DELETE access file. Since NFSv4 does not have a DELETE
access right, nor a OPEN4_SHARE_DENY_DELETE share mode, this text is
unnecessary.

I am not saying we don't need NFS4ERR_FILE_OPEN, because a file could be
opened with SHARE_DENY_DELETE by a CIFS client, for instance. So the
error is very useful, but the above text is what I find questionable.

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

I would remove references OPEN4_SHARE_DENY_WRITE and
OPEN4_SHARE_DENY_BOTH in LINK/RENAME. Recommending to return
NFS4ERR_FILE_OPEN in cases where the server rejects the operation, as
you've described, is sufficient for handling situations where the file
is opened by a CIFS client with SHARE_DENY_DELETE.

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Dec 2007 11:09:49 -0500

> respect to deletion of opened files. 

If it was, it was ill-conceived, but I'm not sure it was.

> I would consider removing this text

If we had a separate DENY_DELETE, then this text would be wrong.

However, given that we don't we have to have some way to decide how 
this situation is dealt with.  Either we treat all opens as having
DENY_DELETE, or none, or some.  RFC3530 chose some, and I don't have
strong feeling about the choice but it would seem odd to me if you 
opened the file specifying that nobody else would be allowed to write
it, but removes were OK.  If you have the spearate DENY_DELETE bit,
then the user can choose this but if he doesn't explicitly choose it,
it does seem a surprising choice.

> error is very useful, but the above text is what I find questionable.

I think these wind up being separate issues.  One is what to do when 
some open prevents the operation and the other is under what situations
the operation should be prevented.

This has been in since RFC3530.  We are free to change in v4.1 but 
I'd like to be sure that we are clear on what the replacement is 
and that we have a consensus that it is better.

> OPEN4_SHARE_DENY_BOTH in LINK/RENAME. 

Actually there aren't any.  It isn't even mentioned in dealing with 
the raname-over case.  I'm guessing that's an oversight.

I'm not sure why DENY_DELETE should prevent LINK but there is not a
current specification that DENY_{WRITE,BOTH} does.

-----Original Message-----
From: Peter Varga [mailto:[email-masked]] 
Sent: Friday, December 14, 2007 10:22 AM
To: [email-masked]
Subject: RE: [nfsv4] NFS4ERR_FILE_OPEN

Good.

---

From: "Peter Varga" <[email-masked]>
Date: Fri, 14 Dec 2007 12:11:22 -0500

You're right that it's two separate issues. I think your suggestions for
NFS4ERR_FILE_OPEN error are certainly improvements.

As for the text in the RFC for the OPEN4_SHARE_DENY_WRITE and
OPEN4_SHARE_DENY_BOTH with respect to file rename/link...

> it does seem a surprising choice.

Here's a scenario for such a use case.

As you know, deny bits apply to all open owners, including the one that
specified the deny bits. Thus, an application may choose to allow for
itself to delete the file while it has it open for write. Consider the
use of a temp file:

handle = Create a temp file with DENY_WRITE only
Delete the temp file (requires opening with DELETE access)

Continue using the handle for the temp file.

This ensures that the temp file is deleted once the application closes
the handle or terminates unexpectedly. Note the app doesn't care if
another app deletes its temp file, as long as it knows that temp data
written to it, which it can continue to access via the open handle,
wouldn't get corrupted by someone else.

Since there are no DELETE and DENY_DELETE in NFSv4, I'm not sure it's a
good idea to shift their functionality into the WRITE and DENY_WRITE
bits.