On 29 September 2013 00:25, Jason Kresowaty <ja...@binarycoder.net> wrote: >> Subject: Re: Respecting inherited Windows file permissions on file create >> From: Ivan Zhakov <i...@visualsvn.com> >> Date: Sat, September 28, 2013 3:29 pm >> Solution (2) is create temporary file in >> wc\a folder. In this case it will get proper inherited permissions >> from wc\a folder. You may try this solution in your test by modified >> permissions of wc\.svn\tmp directory. > > Okay, now I see. That sounds like it would work, but would it make any > patch more or less invasive than it needs to be? > > I really don't mean to argue, but you seem to have not considered if > inserting a SetNamedSecurityInfo API call right after the file move > call would work (and be less invasive than other solutions), as the > Microsoft blogger I referenced previously described. But hey if the > tests pass, why should I complain! > > I could further describe ways to make this work "correctly" using > Windows APIs, including the issue with permissions that were assigned > directly on the file itself. These are probably not going to fit so > cleanly with the abstraction layer in place. And they are not going > to be as simple as calling one function with a bunch of NULL params > as would be the case for SetNamedSecurityInfo. SetNamedSecurityInfo() approach have several problems: 1. Platform depended code. Not a big deal, but makes testing and finding bugs more complicated. 2. File install operation become non-atomic. Subversion should handle SetNamedSecurityInfo() call failure.
> > Note, it is not feasible for me to set up a Windows svn development > environment to actually work on the svn code myself. So I would like > some guidance as to how to best assist with this, or if necessary > better explain this issue. Could you please file issue in Subversion issue tracker: http://subversion.tigris.org/issues/ -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
