Critical Description
In a working copy, different directories may require different Windows permissions (access control lists). For example, some might contain code or data to be accessed by Windows services. Concretely, the Windows service might be a web server and the directory might contain HTML files. For convenience in this reproduction, assume the service runs as "LOCAL SERVICE", an account that comes with Windows. Of special note (but not shown in the following example), different portions of the working copy may require different permissions. For example, this might be because there are several different Windows services involved. For illustration, let's call the working copy root wc and a directory requiring the permissions wc\a. I wouldn't expect (or even want) svn to store Windows permission information in its repository, but I find it undesirable that svn "arbitrarily" interferes with any manually applied permissions, particularly file permissions inherited from parent directories. It is bad form to leave inheritable permissions unpropagated. That this can happen is poorly understood, and it is difficult to troubleshoot in the Windows Explorer GUI when this happens. svn gets itself into trouble when it performs what to the user is logically a file "create" through a physical file "move". This is because Windows has potentially surprising behavior in this case where it does not recalculate the inherited permissions on the file according to its new parent directory. This may appear to be an OS bug in the MoveFile/MoveFileEx API, but Microsoft blogger Raymond Chen does an excellent job explaining how things got to be this way (related to Windows "hard link" support!). The blog post is: "Moving a file does not recalculate inherited permissions" at http://blogs.msdn.com/b/oldnewthing/archive/2006/08/24/717181.aspx. Raymond Chen describes a solution: After performing the MoveFile/MoveFileEx, to "... recalculate [the file's access control entries] from the destination's inheritable properties ... [c]all the SetNamedSecurityInfo function, specifying that you want an empty, unprotected DACL." The reason I think this would be the correct handling is because the move is an implementation detail. The fix causes the permissions to end up to what they would have been had CreateFile been used instead of MoveFile. The follow shows how to reproduce. The call to icacls /reset is analogous to SetNamedSecurityInfo with a NULL DACL. The impact of this problem is that I have to follow svn update or revert operations below directories with inheritable access control entries with calls to the console command icacls /reset, even though the directory tree structure where the permissions are actually assigned was not changed by the svn operation. In practice, this is not lightning fast because I cannot trust the permissions in the subtree and recursively reset everything in the the working copy followed by re-assigning the permissions from scratch which on Windows is proportional to the number of files in the working copy. Commands to reproduce are attached. Mailing list discussion: http://svn.haxx.se/dev/archive-2013-09/0169.shtml
Original issue reported by jasonkresowaty
Attachments
Attachments
Issue Links
- is related to
-
SVN-4478 Checked-out files are not indexed by Windows Search
-
- Open
-