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

Marcel Telka <marcel@telka.sk> Fri, 09 December 2016 22:25 UTC

Return-Path: <marcel@telka.sk>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CBBDB12953C for <nfsv4@ietfa.amsl.com>; Fri, 9 Dec 2016 14:25:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YS9MnnzY-reG for <nfsv4@ietfa.amsl.com>; Fri, 9 Dec 2016 14:25:05 -0800 (PST)
Received: from tortuga.telka.sk (tortuga.telka.sk []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FA312954A for <nfsv4@ietf.org>; Fri, 9 Dec 2016 14:25:04 -0800 (PST)
Received: (qmail 1994 invoked from network); 9 Dec 2016 22:25:01 -0000
Received: from telcontar-wifi.in.telka.sk (HELO telcontar) (marcel@ by tortuga.telka.sk with ESMTPSA (DHE-RSA-AES256-GCM-SHA384 encrypted); 9 Dec 2016 22:25:01 -0000
Date: Fri, 09 Dec 2016 23:25:00 +0100
From: Marcel Telka <marcel@telka.sk>
To: nfsv4@ietf.org
Message-ID: <20161209222500.GB1514@telcontar>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/eINEVFzZeGCBbyfbnJzQwSnGLi0>
Subject: [nfsv4] RFC 7530: Filehandle of opened file after the REMOVE
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 22:25:08 -0000


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

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

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 |