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

[David Noveck <[e-mail]>]

> And, ... what implementors do now with RFC 7530?  If they want to support
> the unix semantics they need to follow the note above albeit it is not
> written in the RFC.

Some implementors already do this, and your note won't affect them.

The problem is with those that don't.  Why would your note cause them to
change course?  I think they will basically figure that clients are going
to do
a silly rename anyway, so they don't have to bother changing their code.

The problem is that NFSv3 made this a client responsibility and NFSv4,0 left
things as they were.  This is not just an issue for Unix.  Making sure an
open file
is not removed out from under the client is a good thing for other OS's as
well.


On Tue, Dec 13, 2016 at 10:58 AM, Marcel Telka <[e-mail]> wrote:

> Citát David Noveck <[e-mail]>:
>
>> I'm late, I know.
>>>
>>
>> I guess I can't resist a (barely) relevant movie quote, from *The Big
>> Short:*
>>
>> Dr. Michael Burry:  I may have been early, but I'm not wrong.
>>
>> Martin Blaine: It's the same thing!
>>
>> You're late with this but there would have been no way that you could have
>> been on time.
>> If you raised this issue in time for RFC3530, I don't think anyone would
>> have listened to
>> you.  You could have stuck to your position, made yourself very unpopular
>> and
>> prevented NFSv4 from happening.
>>
>> RFC3530, RFC7530, RFC 5661 are immutable.  The only way they can be
>> changed
>>
>
> RFC 3530 is maybe immutable, but also obsoleted, so nobody cares
> about it much these days. :-)
>
> Similarly as nobody cares about RFC 3010 now.
>
> is
>> via errata, and your judgment, that we made the wrong choice here is not a
>> good basis
>> for one.
>>
>
> No, I do not suggest that the choice made was wrong.  The current wording
> allows to implement (maybe) simpler NFSv4 servers that do not need to
> bother
> with preserving file handles after the REMOVE (if they do not worry about
> unix).  This is good.
>
>
>> I think this could be addressed in NFSv4 going forward via an extension.
>>
>
> Why not to use the note I suggested (properly rephrased, of course) even
> for RFC 7530 (as errata)?
>
> This one:
>
> "If the server wants to support the unix semantics (a removed file is
> accessible until the last close) then the continued access to the file
> via its file handle until the last CLOSE is essential."
>
> It won't change this (or anything else in RFC 7530, AFAIK):
>
>    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.
>
> It will just add a note (or recommendation, suggestion, clarification,
> whatever) for implementors who want to make sure their NFSv4 servers
> are properly prepared to support the unix semantics for NFSv4 clients.
>
> And, ... what implementors do now with RFC 7530?  If they want to support
> the unix semantics they need to follow the note above albeit it is not
> written in the RFC.
>
>
> Thanks.
>
>
> --
> +-------------------------------------------+
> | Marcel Telka   e-mail:   [e-mail]  |
> |                homepage: http://telka.sk/ |
> |                jabber:   [e-mail] |
> +-------------------------------------------+
>
>