samba - Feb 2016 - vfs_fruit in 4.3.4 Directory Renames with Open Files Problem

Hi Coan,

On Fri, Feb 05, 2016 at 02:39:55PM -0600, Coan Dillahunty
wrote:
> 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),
as previously discussed, we try to be bug compatible with Apple. ;)

The problem is, either way, allowing or not allowing directory renames
with open files, it's a bug for OS X clients. But given the impact of
allowing the rename, I think we should add an option to disallow them
as a workaround. This gives us time until Apple ships a fix.

Do we already have a bugreport for this, and if not, can you file one?

Btw, AFP references files and directories by catalog node IDs (CNIDs)
and not by path, so for this and other reasons they don't care about
renames.

-Ralph

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de,mailto:kontakt at sernet.de

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.

Hello Ralph,

Thank you for your help with this. I've filled a bug report for
this--it's
bug 11721. I agree with the approach of adding an option to disallow
renames with open files until Apple ships a fix.

Interesting how CNIDs work with AFP and how that along with other things in
AFP explains why the renames work correctly over AFP, but not SMB.

Best regards,

Coan

On Fri, Feb 5, 2016 at 2:22 PM, Ralph Boehme <rb at sernet.de> wrote:
> Hi Coan,
>
> On Fri, Feb 05, 2016 at 02:39:55PM -0600, Coan Dillahunty wrote:
> > 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),
>
> as previously discussed, we try to be bug compatible with Apple. ;)
>
> The problem is, either way, allowing or not allowing directory renames
> with open files, it's a bug for OS X clients. But given the impact of
> allowing the rename, I think we should add an option to disallow them
> as a workaround. This gives us time until Apple ships a fix.
>
> Do we already have a bugreport for this, and if not, can you file one?
>
> Btw, AFP references files and directories by catalog node IDs (CNIDs)
> and not by path, so for this and other reasons they don't care about
> renames.
>
> -Ralph
>
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de,mailto:kontakt at sernet.de
>


-- 


Coan Dillahunty
North American Technical Director, TBWA
828 W. 6th St, Austin, TX 78703
+1.512.242.4438 | mobile +1.512.694.4388

-- 


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.