IETF Logo Mail Archive

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

Marcel Telka <marcel@telka.sk> Tue, 13 December 2016 16:56 UTC

Return-Path: <marcel@telka.sk>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50EA129443 for <nfsv4@ietfa.amsl.com>; Tue, 13 Dec 2016 08:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDbNLOPHgfvw for <nfsv4@ietfa.amsl.com>; Tue, 13 Dec 2016 08:56:42 -0800 (PST)
Received: from tortuga.telka.sk (tortuga.telka.sk [185.14.234.118]) (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 143031293FE for <nfsv4@ietf.org>; Tue, 13 Dec 2016 08:56:41 -0800 (PST)
Received: (qmail 3426 invoked from network); 13 Dec 2016 16:56:39 -0000
Received: from localhost (HELO tortuga.telka.sk) (127.0.0.1) by localhost with SMTP; 13 Dec 2016 16:56:39 -0000
Received: from tyhog-gua01a-216.cronon.net (tyhog-gua01a-216.cronon.net [192.166.200.216]) by mail.telka.sk (Horde Framework) with HTTPS; Tue, 13 Dec 2016 16:56:39 +0000
Date: Tue, 13 Dec 2016 16:56:39 +0000
Message-ID: <20161213165639.Horde.t6BGVBJqifWKHucfa069yT8@mail.telka.sk>
From: Marcel Telka <marcel@telka.sk>
To: David Noveck <davenoveck@gmail.com>
References: <20161209222500.GB1514@telcontar> <CADaq8jck1P2vcDZjaFSnQRFYUnAyjJCqDgxqdWPDhEjPP7hDmA@mail.gmail.com> <20161213113547.Horde.wCZotJjSqGlvU03mq8Ptel3@mail.telka.sk> <CADaq8je40Siv5r9r2gd8b+n4P_qeueBpxuASTsaQLHV5jca7yA@mail.gmail.com> <20161213155825.Horde.vsqZuNSZ9hIXlcHQYxmgRC7@mail.telka.sk> <CADaq8jeiwGwgV=_HHjR2D4uNaKq9zY96hJOVXp4Q0H-3OgH2qA@mail.gmail.com>
In-Reply-To: <CADaq8jeiwGwgV=_HHjR2D4uNaKq9zY96hJOVXp4Q0H-3OgH2qA@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/nfsv4/eOQzrbdsiPQRU-jbYxWLeFKGsMo>
Cc: nfsv4@ietf.org
Subject: Re: [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: Tue, 13 Dec 2016 16:56:44 -0000

Citát David Noveck <davenoveck@gmail.com>:
>> 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

My note will suggest them that if they want the unix semantics they will
be clearly instructed what they need to implement.

Now, without the note, it is not clear what exactly needs to be done to get
the unix semantics.

> to do
> a silly rename anyway, so they don't have to bother changing their code.

Sure, they have an option to do not implement the unix semantics, if they will
decide so.

Anyway, it is not possible to implement unix semantics using the silly
rename only.  Or, do you suggest that all removes should be done as
silly renames?

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

How can a NFSv4 client do that without help from either server or other
client(s)?

Please return back to my example in the first mail.  What needs the clientA
to do to make sure its file does not disappear?  If the answer is "nothing, it
is responsibility of clientB to do the silly rename" then:

1) we do not need the REMOVE operation :-)
2) how we will make sure that _all_ clients will do the silly
    rename (including NFSv2 clients, NFSv3 clients, NFSv4.1 clients,
    NFSv4.2 clients, NFSv4.3 clients, NFSv5.0 clients, CIFS
    clients, and local processes)?


Thanks.

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   marcel@telka.sk  |
|                homepage: http://telka.sk/ |
|                jabber:   marcel@jabber.sk |
+-------------------------------------------+

v2.23.0 | Report a Bug | By Email