Bug 10726 - acl handling when moving files with MoveSecurityAttributes set to 0
Summary: acl handling when moving files with MoveSecurityAttributes set to 0
Status: RESOLVED INVALID
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 enhancement (vote)
Target Milestone: ---
Assignee: Stefan Metzmacher
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-18 12:40 UTC by Björn Jacke
Modified: 2014-10-13 10:52 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Jacke 2014-07-18 12:40:40 UTC
windows allows alternative acl semantics when files are being moved on one NTFS volume. With

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MoveSecurityAttributes = 0 (on the client)

the ACLs are being set like if the file would have been copied there and not moved. This worked with Windows XP. With Windows 7 and Vista a hotfix was needed to make this work:

http://support.microsoft.com/kb/2617058

See also
http://support.microsoft.com/kb/310316

We should also support this MoveSecurityAttributes=0 semantic.
Comment 1 Björn Jacke 2014-07-29 12:52:42 UTC
by the way with win XP MoveSecurityAttribytes defaults to 1 (ACLs stay)

with Win 7 the default behaviour is MoveSecurityAttribytes=0 but the registry key only comes with the before mentioned hotfix. The resetting of the ACLs is being done by Explorer on client-side however, not by the server.

the kb2617058 is also quite confusingly written as is only suggests to set MoveSecurityAttribytes=0 - which is already the Win 7 default. The patch allows to do the opposite - set that thing to 1 again - to the XP default.

nice read about this:
http://blogs.msdn.com/b/oldnewthing/archive/2013/09/24/10451467.aspx

looks like there is actually nothing to do for us here.