Re: [PATCH 0/3] cifs: some random patches for 2.6.31

On Mon, 2009-05-25 at 13:28 -0400, Jeff Layton wrote:
> On Mon, 25 May 2009 12:42:42 -0400
> simo <[email protected]> wrote:
> 
> > On Mon, 2009-05-25 at 06:14 -0400, Jeff Layton wrote:
> > > On Sun, 24 May 2009 21:05:42 -0400
> > > simo <[email protected]> wrote:
> > > 
> > > > Also on the mandatory issue, I wonder if applications
> > > > ever check it in the real world. If not, then either way is fine,
> > > > otherwise having the bit set would give precious hints.
> > > > (Although I prefer the patch as it is rather than leaving permission as
> > > > open as they are now).
> > > >
> > > 
> > > I doubt applications ever look at this. If they do, then they also need
> > > to pay attention to the "mand" mount option and I'm pretty sure that
> > > checking that wouldn't be portable anyway. This change is really about
> > > whether we want the kernel's VFS layer to enforce mandatory locking on
> > > these files.
> > 
> > Yes if apps never look at it (as I believe too) then it is probably just
> > useless to set the locking as mandatory, although in that case shouldn't
> > we prevent sending advisory locks to the server if unix extensions are
> > not negotiated ? (do we already do that?)
> > 
> 
> Currently, we actually attempt to map posix advisory locks to windows
> mandatory locks. There are obvious semantic differences here, so this
> mapping is not perfect, but I think we do as well as be expected given
> the differences. We could consider disabling this mapping somehow, but
> in most cases people probably do want some sort of lock set on the
> server when they set an advisory lock.
> 
> This is a pretty complex topic, but I think with this change we'll have
> a sane set of default behaviors relating to the mode (well, as sane as
> we can expect given the issues with Windows<->Linux semantics).

I was thinking that maybe we should send locks only when we explicitly
make them mandatory. As we are not respecting them on the client anyway
when they are not.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <[email protected]>
Principal Software Engineer at Red Hat, Inc. <[email protected]>