[PATCH] flock() files even with a permissive share mode.

Christof Schmitt cs at samba.org
Mon Feb 4 18:31:20 UTC 2019

On Sat, Feb 02, 2019 at 06:26:17PM +0100, Volker Lendecke via samba-technical wrote:
> On Fri, Feb 01, 2019 at 08:38:04PM -0500, Matthew Stickney via samba-technical wrote:
> > I've only just begun poking around the samba code, so apologies if I've
> > missed something obvious (or if this is the wrong list for this sort of
> > question).
> This is exactly right. The problem with this API is -- nobody cares.
> You are the first one in MANY years who has taken a look.
> Whenever I have the chance to meet NFS people, I literally beg for
> their precious time to discuss interoperable locking. We need to at
> least talk about the intended semantics: What does a share mode in SMB
> mean for NFS share reservations, and how do we properly communicate
> that? What about mandatory vs advisory? What about leases/oplocks vs
> delegations? What is a good break mechanism? We need to sort this out
> in user space before we can even start approaching the kernel.
> The NFS people I met do not see this as a priority, nobody ever could
> allocate time. Locking seems to be a topic nobody outside the SMB
> world ever looks at. We need to keep the VFS call in, because I know
> of at least one vendor who has this implemented in his proprietary
> file system. For the rest -- I don't think it matters if we keep it
> in.

Do you mean what we have implemented for gpfs? Or is there another file
system that can enforce share modes?

I see the problems with the flock call. The main advantage of keeping it
would be having an easy way to test the vfs call. We could add a test
for this to autobuild to ensure that the codepath is excersized, but if
gpfs is the only actual user, that probably would fall on me.


More information about the samba-technical mailing list