From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76578C04AA6 for ; Tue, 30 Apr 2019 09:22:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4736520835 for ; Tue, 30 Apr 2019 09:22:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JcInW5rB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726539AbfD3JWm (ORCPT ); Tue, 30 Apr 2019 05:22:42 -0400 Received: from mail-yw1-f49.google.com ([209.85.161.49]:44273 "EHLO mail-yw1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725938AbfD3JWl (ORCPT ); Tue, 30 Apr 2019 05:22:41 -0400 Received: by mail-yw1-f49.google.com with SMTP id j4so5349066ywk.11; Tue, 30 Apr 2019 02:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=O71BR93nfVKV7X+BaaevcM23d4NroedovEN8YpLCNFc=; b=JcInW5rB9D8GUPZ8eanzEAStA6lvRQhboAjNfLzzLdXysYXomWALWwxj8+wTzvVYpa jLBy7vcbQaJD7mn8T5Sntys7faEG9YVKoEsGk7SwAh6x6cEYHNgmj8A2haTuJ+kyho0w ZloKwHb4U+H7rrb30t5RK0fyGo//KfIGrV7iYEYDfmnKtk/4nU3zTb2cnI0ux3hc2VF5 MFyzzzTCYOA3bKMbJEnpkbcJGTbyxNno8ZMlD/MqkP3wKpg4r67bP3mhDMRpFThrIpcB tP9+3s8Xdq/IhNwAbwJJBEstIfHnp22w7/Kbmxgi5D9Ezmvu6/T0JG1EBV0Vwc/j2rrY X9Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=O71BR93nfVKV7X+BaaevcM23d4NroedovEN8YpLCNFc=; b=n/P08XTB0SjWLtHzLHFsDXCv6G+n4JNLH3uKGZdzQTUs5R6WRmenWTHoE3h9xbZBmd ACuAMCgOPEiNN3hWSKvy8hTIP9qW8T5n3fJi+Bu1t2BuOSS35e31RgMo4+GBPE5ZlXET RYmKqkxCLsmr1/1xi7VMsRxJyNDRCWN2Ws80IJLA0oY4bDKxHnTxc3b9cQUIOG2ZVCbw wPHBX064ddezedF+ZekUSVQfgmR2wnL5HTqrNcmBtKzhkVVq/eXuQqvUL8in9X1zetZW 99VPNanzg/ByOCqQ669/c9OeNb6L62vxb+1223H6wckvynffpsLOeFpdU4uSV7S0DtXL Mktg== X-Gm-Message-State: APjAAAU1hUQJlxQ1CeCB1145ig/fgGM6+Nux1Ie9WXQVeOq0cHB+37xi O7xeBWTSIO0m0BIF6QM45dQGlkzBS+QncnRYKXI= X-Google-Smtp-Source: APXvYqyJZqlIcP4RcRxCE9J+CCDpDAOQezVG4wmzGr92TpdSb96QB+9P1jtwCzw83+ORzm1Cz6J4GtL1iisDo0MaJVw= X-Received: by 2002:a81:1150:: with SMTP id 77mr54593542ywr.241.1556616160900; Tue, 30 Apr 2019 02:22:40 -0700 (PDT) MIME-Version: 1.0 References: <20190426145006.GD25827@fieldses.org> <8504a05f2b0462986b3a323aec83a5b97aae0a03.camel@kernel.org> <1d5265510116ece75d6eb7af6314e6709e551c6e.camel@hammerspace.com> <95bc6ace0f46a1b1a38de9b536ce74faaa460182.camel@hammerspace.com> <677e86ee-59b9-0826-481f-955074d164ed@samba.org> In-Reply-To: <677e86ee-59b9-0826-481f-955074d164ed@samba.org> From: Amir Goldstein Date: Tue, 30 Apr 2019 05:22:29 -0400 Message-ID: Subject: Re: Better interop for NFS/SMB file share mode/reservation To: Uri Simchoni Cc: Pavel Shilovskiy , "linux-nfs@vger.kernel.org" , "Volker.Lendecke@sernet.de" , Jeff Layton , "samba-technical@lists.samba.org" , Trond Myklebust , "linux-fsdevel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, Apr 30, 2019 at 4:12 AM Uri Simchoni wrote: > > On 4/30/19 3:31 AM, Amir Goldstein via samba-technical wrote: > >> > >> About O_DENYDELETE: I don't understand how we may reach a good interop= story without a proper implementation of this flag. Windows apps may set i= t and Samba needs to respect it. If an NFS client removes such an opened fi= le, what will Samba tell the Windows client? > >> > > > > Samba will tell the Windows client: > > "Sorry, my administrator has decided to trade off interop with nfs on > > share modes, > > with DENY_DELETE functionality, so I cannot grant you DENY_DELETE that = you > > requested." > > Not sure if that is workable. Samba developers need to chime in. > > > > Thanks, > > Amir. > > > > On Windows you don't ask for DENY_DELETE, you get it by default unless > you ask to *allow* deletion. If you fopen() a file, even for > reading-only, the MSVC standard C library would open it with delete > denied because it does not explicitly request to allow it. My guess is > that runtimes of other high-level languages behave that way too on > Windows. That means pretty much everything would stop working. > I see. I was wondering about something else. Windows deletes a file by opening it for DELETE_ON_CLOSE and then "The file is to be deleted immediately after all of its handles ar= e closed, which includes the specified handle and any other open or duplicated handles.". What about hardlinks? Are open handles associate with a specific path? not a specific inode? I should note that Linux NFS client does something similar called silly rename. To unlink a file, rename it to temp name, then unlink temp name on last handle close to that file from that client. If, and its a very big if, samba could guess what the silly rename temp nam= e would be, DENY_DELETE could have been implement as creating a link to file with silly rename name. Of course we cannot rely on the NFS client to enforce the samba interop, but nfsd v4 server and samba could both use a similar technique to coordinate unlink/rename and DENY_DELETE. Thanks, Amir.