[Samba] vfs_fruit in 4.3.4 Directory Renames with Open Files Problem

[Coan Dillahunty]

 Hello Everyone,

We've observed a problem in with the latest version of samba and vfs_fruit
and was wondering if anyone has seen the same problem.

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:
https://bugzilla.samba.org/show_bug.cgi?id=11065

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), although their AFP implementation doesn't share this problem
and works like this:

The directory change for User B is allowed and User A is still able to save
without error.

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.

Thanks,

Coan

-- 


This e-mail is intended only for the named person or entity to which it is addressed and contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure. If you received this e-mail in error, any review, use, dissemination, distribution or copying of this e-mail is strictly prohibited. Please notify us immediately of the error via e-mail to disclaimer at email-abuse.com and please delete the e-mail from your system, retaining no copies in any media. We appreciate your cooperation.