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. Traces attached. [1] <https://msdn.microsoft.com/en-us/library/ff469527.aspx>
Created attachment 10646 [details] Trace showing the spec conforming behaviour of Samba
Created attachment 10647 [details] Trace showing behaviour of OS X 10.9 SMB server
Created attachment 10648 [details] Possible implementation to allow POSIX dir renames
As I mentioned on the list, we need to know first if this is an Apple SMB server bug, or something that should be selected if the AAPL create context or POSIX semantics are specified.
Created attachment 10652 [details] Rename dir with open file, smbclient to 10.9 SMB2 connection without AAPL (smbclient to 10.9): server allows rename.
If it allows it on SMB2 without AAPL, that's just a server bug :-(.
Hm, according to man smb.conf "strict rename" defaults to "no", as such we shouldn't be enforcing this which contradicts smbd behaviour, at least for SMB2.
Comment on attachment 10648 [details] Possible implementation to allow POSIX dir renames Hate this, it's a horrible hack :-). Might be better to add a NSTATUS VFS rename_fsp() call which allows modification at the NTFS emulation layer.
(In reply to Jeremy Allison from comment #8) What is the right behavior here in the case of mixed clients? With just AAPL/POSIX clients I can see the behavior of allowing the rename as being good. But if you have a real "Windows" style client in there, might blocking the rename be right? Just something to think on?
Created attachment 11616 [details] git-am fix for 4.3.next, 4.2.next. This doesn't fix the underlying Mac bug - but is part of the ultimate patchset we'll need. Cherry-picked from master.
Not assigning to Karolin as this still misses patches for the underlying issue.
Created attachment 11668 [details] Patch for 4.2 cherry-picked from master This one has to go on top of Jeremy's patch "git-am fix for 4.3.next, 4.2.next.".
Created attachment 11669 [details] Patch for 4.3 cherry-picked from master This one has to go on top of Jeremy's patch "git-am fix for 4.3.next, 4.2.next.".
Comment on attachment 11668 [details] Patch for 4.2 cherry-picked from master Only one quick question before I +1 this - is there any platform where sizeof(bool) != sizeof(uint8_t) ? Or any platform where this change might make an ABI difference. I can't think of any right now, but wanted to at least ask the question. Jeremy.
Never mind. The only one I was worried about was ARM, then I found this: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/Babfcgfc.html
Re-assigning to Karolin for inclusion in 4.2.next, 4.3.next.
(In reply to Jeremy Allison from comment #16) Pushed to autobuild-v4[3|2]-test.
Pushed to both branches. Closing out bug report. Thanks!
I have debian jessie with sernet samba 4.2.8 intalled. I have a problems that I think are similar to this: FolderTest - FileTest1 - FileTest2 - If I have the folder "FolderTest" selected with an OSX client and I try to delete the folder from a different OSX client, the content is deleted but not the folder because a "File in use" error. If I try again to delete the folder with empty content(that was previously deleted) the It works. - If I have the file "FileTest1" selected with an OSX client and I try to delete the folder from a different OSX client, fails due to the error "File in use" and nothing is deleted. - If I have the file "FileTest2" selected with an OSX client and I try to delete the folder from a different OSX client, the content is deleted but not the folder because a "File in use" error. - If I try to replace the folder "FolderTest" with other with the same name and same content then the content in the server is deleted. Regards,
Hm, looks like Jeremy's patch https://attachments.samba.org/attachment.cgi?id=11616 wasn't pushed to 4.2 and 4.3. What shall we do with the drunken sailor?
(In reply to Ralph Böhme from comment #20) Push for next releases ?
(In reply to Ralph Böhme from comment #20) Sorry, this happened by accident. Unfortunately, the patch does not apply on current v4-3-test. Additionally, the last 4.2 maintenance release has been shipped today. Do we need another one?
I'll prepare a patch for 4.3
Not worth another 4.2 IMHO. Jeremy.
Created attachment 12186 [details] Missing patch for 4.3, cherry-picked from master
(In reply to Jeremy Allison from comment #24) I agree, this doesn't justify another 4.2 release
Reassigning to Karolin for inclusion in 4.3.next.
(In reply to Jeremy Allison from comment #27) Pushed additional patches to autobuild-v4-3-test. Thanks!
(In reply to Karolin Seeger from comment #28) Pushed to v4-3-test. Closing out bug report. Thanks!