Samba 4.3.4 with vfs_fruit enabled allows a Mac client to rename a directory when another client has another client has open files in that directory. The fix for this bug brought this functional change to vs_fruit:
BUG 11065: vfs_fruit: Enable POSIX directory rename semantics:
Directory renames work as planned by the new functionality, but this causes problems for the clients that had open files in the changed path. When attempting to save, applications lose track of the current path and prompt the user for a new location to save or fail to save and the user must force close the application.
Environment tested: Mac OS X 10.11.x with Samba 4.3.4.
Applications tested: TextEdit, MS Word 2011 and 2016, Adobe Photoshop CC 2014
Assume a directory structure like this:
Top level: Folder 1: Folder 2: Folder 3: Folder 4: Test.docx
User A has "Test.docx" open for editing and User B renames "Folder 4" to be something else. This change is allowed, but User A is unable to save the file or gets prompted where to save the file after User B has renamed the parent directory (or another directory in the path such as "Folder 3"). This behavior is potentially dangerous or at least disruptive, since User A is unable to save changes to the file after the directory has been renamed. Different applications handle the rename differently, with most indicating that the current path is invalid and prompting for a new location to save. Adobe Photoshop CC 2014 is even worse, failing on save and then not allowing other attempts to save with an error that another save is pending completion.
Apple's SMB implementation in Server 5.0.15 on El Capitan 10.11.2 exhibits the same problem and I’ve opened a case with Apple about the issue (case 1029666009).
FYI, I've confirmed that this is not because of a permissions issue--permissions are okay and User A is able to read and write the file in question after disconnecting from the share and reconnecting to the SMB share.
If this bug can't be fixed, a runtime option to disable the change introduced to fix bug 11065 could be useful so that end users are not impacted by renames. We've already experienced several instances of lost work caused by directory renames.
While I originally thought that allowing POSIX rename semantics only allowed directory renames when open files were present in the directory, I was incorrect. Supporting POSIX rename semantics also allows the rename of a file that is open. I've tested this against Samba 4.3.4 with Apple OS Version 10.11.4 and with Apple Server on 10.11.4 and Mac OS X 10.11.4 as the client. Renames of directories with open files and renames of files that are read/write by another user are both allowed. Both of these rename types break the ability of the user with the open file to save after the rename completes.
I am seeing a similar issue that may be related where a user cannot rename a top-level folder after working on files below its path (apps are indesign and photoshop on Mac OS 10.10 and 10.11 clients). Server is samba 4.3.8 on FreeBSD ZFS.
Could this be related or am I better opening a separate issue?
(In reply to pascal.guitierrez from comment #2)
That should be fixed by #11065.
Created attachment 12072 [details]
git-am fix for 4.4.next, 4.3.next.
Cherry-picked from master.
Reassigning to Karolin for inclusion in 4.3 and 4.4.
(In reply to Ralph Böhme from comment #5)
Pushed to autobuild-v4-[3|4]-test.
(In reply to Karolin Seeger from comment #6)
Pushed to both branches.
Closing out bug report.