Bug 11721 - Directory Renames with Open Files Problem
Summary: Directory Renames with Open Files Problem
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 4.3.4
Hardware: All Mac OS X
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2016-02-08 17:01 UTC by Coan Dillahunty
Modified: 2016-05-11 11:33 UTC (History)
2 users (show)

See Also:

git-am fix for 4.4.next, 4.3.next. (2.41 KB, patch)
2016-05-05 00:32 UTC, Jeremy Allison
slow: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Coan Dillahunty 2016-02-08 17:01:07 UTC
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.
Comment 1 Coan Dillahunty 2016-03-29 20:33:50 UTC
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.
Comment 2 pascal.guitierrez 2016-04-15 07:20:12 UTC
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?
Comment 3 Ralph Böhme 2016-04-15 08:08:36 UTC
(In reply to pascal.guitierrez from comment #2)
That should be fixed by #11065.
Comment 4 Jeremy Allison 2016-05-05 00:32:51 UTC
Created attachment 12072 [details]
git-am fix for 4.4.next, 4.3.next.

Cherry-picked from master.
Comment 5 Ralph Böhme 2016-05-05 06:24:05 UTC
Reassigning to Karolin for inclusion in 4.3 and 4.4.
Comment 6 Karolin Seeger 2016-05-09 08:11:17 UTC
(In reply to Ralph Böhme from comment #5)
Pushed to autobuild-v4-[3|4]-test.
Comment 7 Karolin Seeger 2016-05-11 11:33:51 UTC
(In reply to Karolin Seeger from comment #6)
Pushed to both branches.
Closing out bug report.