Re: Better interop for NFS/SMB file share mode/reservation

From: Amir Goldstein <amir73il@gmail.com>
To: Uri Simchoni <uri@samba.org>
Cc: Pavel Shilovskiy <pshilov@microsoft.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"Volker.Lendecke@sernet.de" <Volker.Lendecke@sernet.de>,
	Jeff Layton <jlayton@kernel.org>,
	"samba-technical@lists.samba.org"
	<samba-technical@lists.samba.org>,
	Trond Myklebust <trondmy@hammerspace.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: Better interop for NFS/SMB file share mode/reservation
Date: Tue, 30 Apr 2019 05:22:29 -0400	[thread overview]
Message-ID: <CAOQ4uxiwDPDyQPrPkUzZCO8jkySRiSK+AZu1dxppXvVA4q6XnA@mail.gmail.com> (raw)
In-Reply-To: <677e86ee-59b9-0826-481f-955074d164ed@samba.org>

On Tue, Apr 30, 2019 at 4:12 AM Uri Simchoni <uri@samba.org> 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 it and Samba needs to respect it. If an NFS client removes such an opened file, 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 are
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 name
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.