Windows vs POSIX directory rename with open files behaviour

[Jeremy Allison]

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 ?

> > ...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.

> 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.

Sounds like a server bug to me. After all, those clients
would fail against Windows in the same way. Unless it's
the addition of the AAPL create context switch that
changes the behavior.

But we need to know that :-).