Bug 9962 - RHEL 6.4 Samba 3.6 file rename behavior change not documented
RHEL 6.4 Samba 3.6 file rename behavior change not documented
Status: RESOLVED WORKSFORME
Product: Samba 3.6
Classification: Unclassified
Component: VFS Modules
3.6.9
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-20 14:03 UTC by Richard
Modified: 2013-07-13 07:31 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard 2013-06-20 14:03:16 UTC
RHEL 6.4 samba-3.6.9-151 includes a Samba file rename behavior change
that is not documented in the Samba nor RHEL Release Notes and breaks
some Samba client-side applications (e.g., Microsoft Word from
Microsoft Office for Mac 2008 and 2011)

The error encountered with Microsoft Office for Mac 2011 Word while
trying to save to an existing document;

"Word cannot save this document due to a naming or permissions
error on the destination volume."

The user's Word .docx document is 'lost' with only temporary files
(e.g., Word Work File L_2.tmp and ._Word Work File L_2.tmp) remaining.

The error is caused by the Samba 3.6 server-side file rename routine,
vfswrap_rename(), when the routine attempts and fails to rename a file
across filesystems resulting in a Samba response of
STATUS_NOTE_SAME_DEVICE (rename(2) EXDEV).  Some Samba client-side
application do not handle the error gracefully.  

Samba 3.5 and earlier client-side applications do not need to handle
the rename() EXDEV situation because Samba 3.5 routine vfswrap_rename()
does automatically rename a file across filesystems.

The work-around is to enable the Samba 3.5 file rename behavior via the
Samba 3.6 newly introduced crossrename VFS module.  Module crossrename
is not enabled by default.  To enable the module, update smb.conf;

   vfs objects = crossrename
     crossrename:sizelimit = 300                (300=300MB, 20MB is default)

See man vfs_crossrename(8).

BTW, RHEL 6.3 supplies samba-3.5.10-125.
Comment 1 Björn Jacke 2013-06-20 16:15:21 UTC
Karo: your decision if you want to change the release notes of 3.6 for this retroactively. I'm not sure if this is a good idea.

Richard: if you report the OS X client bug to Apple (bugreport.apple.com), you might wanna post the link to the report here. Thanks! BTW: I'm surprised that the temporary dot files from office are not on the same filesystem, I thougt they would be in the same directory, which should usually be the same filesystem ... :)
Comment 2 Richard 2013-06-20 18:52:49 UTC
Good day Bjorn,

I suspect Microsoft, not Apple, would need to change Microsoft Word code -- I need to verify.

It is ugly but Microsoft Word does work with temporary files in the working directory but also attempts to create/use in the share root directory a directory named .TemporaryItems and file ._.TemporaryItems.  It is during the process of renaming the temporary file within the share root .TemporaryItems directory to the working directory that the rename() is attempted and fails if the share root is on a different filesystem than the working directory.  At that point Word produces the error and the original file no longer exist in name.
Comment 3 Björn Jacke 2013-06-24 12:43:51 UTC
On 2013-06-20 at 18:52 +0000 samba-bugs@samba.org sent off:
> https://bugzilla.samba.org/show_bug.cgi?id=9962
> 
> --- Comment #2 from Richard <rjackson.richard@gmail.com> 2013-06-20 18:52:49 UTC ---
> Good day Bjorn,
> 
> I suspect Microsoft, not Apple, would need to change Microsoft Word code -- I
> need to verify.
> 
> It is ugly but Microsoft Word does work with temporary files in the working
> directory but also attempts to create/use in the share root directory a
> directory named .TemporaryItems and file ._.TemporaryItems.  It is during the
> process of renaming the temporary file within the share root .TemporaryItems
> directory to the working directory that the rename() is attempted and fails if
> the share root is on a different filesystem than the working directory.  At
> that point Word produces the error and the original file no longer exist in
> name.

if the Darwin's smbfs translated to EXDEV on the posix layer on a rename and
"mv" for example works right then it is a Office bug, right. You will see the
same problem also without smbfs but with local filesystem mounts.
Comment 4 Richard 2013-06-24 17:17:31 UTC
Bjorn,

Agreed.  The Samba 3.6 file rename function behavior change does highlight a flaw in the way Mac/Word handles a file rename across filesystems with or without Samba.  The motivation for this report is to have the Samba 3.6 Release Notes document the Samba 3.6 behavior change.  Getting Microsoft/Apple to correct/change Mac/Word is a different challenge.  :)
Comment 5 Karolin Seeger 2013-06-27 07:11:07 UTC
Changing the release notes now does not make sense, I think.
Closing out bug report.

Thanks!
Comment 6 Richard 2013-06-27 10:18:05 UTC
Documenting the Samba 3.6 file rename behavior change does make sense in the next Samba 3.6 series release.  Think if it as a bug that was introduced earlier but addressed with the latest Samba 3.6 series release.  It may not make sense in the original 3.6 release notes  at this point if there is no practical mechanism.