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

Marcel Telka <> Tue, 13 December 2016 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2462129411 for <>; Tue, 13 Dec 2016 07:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DNkJC53TFB83 for <>; Tue, 13 Dec 2016 07:58:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BA751296B4 for <>; Tue, 13 Dec 2016 07:58:28 -0800 (PST)
Received: (qmail 1018 invoked from network); 13 Dec 2016 15:58:25 -0000
Received: from localhost (HELO ( by localhost with SMTP; 13 Dec 2016 15:58:25 -0000
Received: from ( []) by (Horde Framework) with HTTPS; Tue, 13 Dec 2016 15:58:25 +0000
Date: Tue, 13 Dec 2016 15:58:25 +0000
Message-ID: <>
From: Marcel Telka <>
To: David Noveck <>
References: <20161209222500.GB1514@telcontar> <> <> <>
In-Reply-To: <>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset="utf-8"; format="flowed"; DelSp="Yes"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [nfsv4] RFC 7530: Filehandle of opened file after the REMOVE
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Dec 2016 15:58:31 -0000

Citát David Noveck <>:
>> 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

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.


| Marcel Telka   e-mail:  |
|                homepage: |
|                jabber: |