Questions about smbd option "strict rename"

[Jeremy Allison]

On Wed, Nov 25, 2015 at 06:15:19PM +0100, Ralph Boehme wrote:
> On Wed, Nov 25, 2015 at 08:57:52AM -0800, Jeremy Allison wrote:
> > On Wed, Nov 25, 2015 at 03:50:25PM +0100, Ralph Boehme wrote:
> > > On Tue, Nov 24, 2015 at 10:01:11AM -0800, Jeremy Allison wrote:
> > > > On Tue, Nov 24, 2015 at 06:50:47PM +0100, Ralph Boehme wrote:
> > > > > Jeremy, how to proceed wrt that attaching POSIX rename behaviour to
> > > > > POSIX pathnames is wrong imo. We need a seperate flag for this.
> > > > 
> > > > I don't think it is wrong. We have behaved that way
> > > > for a *very* long time and in the same way we
> > > > attach POSIX delete behavior to POSIX pathnames
> > > > too. Changing that will break UNIX extensions.
> > > 
> > > sorry if you got the impression I would want to change semantics, I
> > > don't! I merely want to tweak the internal handling by allowing more
> > > fine grained control *without* changing existing CIFS UNIX extensions.
> > > 
> > > > Now you might want an additional flag in order to
> > > > get POSIX-rename (and maybe POSIX-delete) behavior
> > > > for MacOSX clients that don't currently negotiate
> > > > UNIX extensions, but that's different from changing
> > > > the current smbd behavior.
> > > 
> > > Again, I don't want to change existing behaviour.
> > > 
> > > Maybe the attached patch makes clearer what I have in mind.
> > 
> > Oh, that makes much more sense, thanks !
> 
> :)
> 
> > I still have adding fields into files_struct
> > as a kitchen sink for underlying behavior.
> 
> Maybe add a uint64_t for flags, ie "uint64_t posix_flags" ? Just
> thinking loud.

Oh that's a nice idea. I think for the specific
issue at hand (OSX clients wanting some but
not all POSIX behavior) that's a perfect
solution.

When POSIX_OPEN is passed in, we set all
flags to ge the current behavior and then
the OSX client can unset (or set) flags
at will inside the fruit VFS.