On 29 September 2013 00:25, Jason Kresowaty <jason_at_binarycoder.net> wrote:
>> Subject: Re: Respecting inherited Windows file permissions on file create
>> From: Ivan Zhakov <ivan_at_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:
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-09-28 23:17:58 CEST