Windows vs POSIX directory rename with open files behaviour

[Ralph Böhme]

On Thu, Jan 22, 2015 at 09:50:49AM -0800, Jeremy Allison wrote:
> On Thu, Jan 22, 2015 at 06:40:28PM +0100, Ralph Böhme wrote:
> > On Thu, Jan 22, 2015 at 09:19:36AM -0800, Jeremy Allison wrote:
> > > On Thu, Jan 22, 2015 at 10:17:35AM +0100, Ralph Böhme wrote:
> > > > Hi!
> > > > 
> > > > Bug: <https://bugzilla.samba.org/show_bug.cgi?id=11065>
> > > > 
> > > > Looks like Apple's SMB server deviates from the standard in that it
> > > > allows renames of directories with open files. As specified in [1], a
> > > > SMB server MUST deny renames of directories with open files with an
> > > > error code of STATUS_ACCESS_DENIED.
> > > > 
> > > > Haven't checked yet whether there are dependencies on protocol level,
> > > > capabilities or something else. The basic behaviour is just that with
> > > > a 10.10 -> 10.9|10 SMB2 connection, renaming directories with open
> > > > files works.
> > > > 
> > > > Possible patch: <https://bugzilla.samba.org/attachment.cgi?id=10648>
> > > > 
> > > > Thoughts? :)
> > > 
> > > Is this only with the AAPL create context added ?
> > 
> > no, it's the same with a SMB1 connection.
> > 
> > > Does the Apple SMB server allow renames with a
> > > normal Windows SMB2 create context, ...
> > 
> > That's not how Apple uses the AAPL create context: it's *not* passed
> > in every create request, but only in an *initial* create on the share
> > root path. That initial, unique AAPL request and reply serve as an
> > additional capability negotation transport. :)
> 
> So what happens if we use smbclient - which doesn't
> send the initial AAPL create context ?
> 
> Does the Apple SMB1/SMB2 server allow renames on open
> files than ?

yes. I've attached a tcpdump to the bugreport.

> > > ...not including
> > > the AAPL context, or does it disallow them like
> > > the Windows server does.
> > > 
> > > I'm happy we know about this, but I'm worried
> > > about emulating bugs in a third party server
> > > (we have enough of our own :-).
> > 
> > I'd say it's not a bug, but Apple is trying to squeeze out POSIX
> > semantics.
> 
> Well that's what the POSIX capability bit is for.

We don't have that in an SMB2 context. :) I'm piggy packing POSIX
behaviour on top of vfs_fruit, probably just like Apple is piggy
packing it left and right as needed in order to make their POSIX
client system happy.

> > The original bug report that shoved me into investigating this was
> > saying that the OS X Finder occasionally wasn't able to rename folder
> > on a Samba 4.1.16 server, for the reason that there were open files
> > (.DS_Store, used by the Finder itself to store directory appearance
> > properties).
> 
> Interesting. I think we need to know *exactly* what semantics
> this requires before we try and emulate it.

Not sure to what *this* refers to here, but if I thing for the
*rename* semantics we need exactly this: in an SMB2 context with AAPL
extension allow directory renames without checking for open files in
the filesystem tree rooted in directory.

> Sounds like a server bug to me.

I don't think so. Sounds like poor-mans SMB2 POSIX extensions to me. :)

> After all, those clients would fail against Windows in the same way.

Definitely.

> Unless it's the addition of the AAPL create context switch that
> changes the behavior.

The behaviour is the same irrespective of AAPL create contexts.

Thanks for taking time and looking into this!
-Ralph

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de,mailto:kontakt@sernet.de