On 28 September 2013 22:00, <ja...@binarycoder.net> wrote: > 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 don't expect (or event 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. svn > seems to get 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. > I see two possible solutions for this problem: 1. Use hTemplate argument in CreateFile call when temporary file is created 2. Created temporary file along original file to be replaced instead of .svn/tmp in working copy root
Option (1) is hard to because APR abstraction, while (2) should be easier but solve only problem when file itself doesn't have specific permissions. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
