Questions about smbd option "strict rename"
jra at samba.org
Wed Nov 25 17:31:14 UTC 2015
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
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.
More information about the samba-technical