[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Respecting inherited Windows file permissions on file create

From: Jason Kresowaty <jason_at_binarycoder.net>
Date: Sat, 28 Sep 2013 13:25:36 -0700

> 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.

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. (i.e., if I haven't adequately explained
that it is bad form to leave inheritable permissions unpropagated on
Windows. The Explorer shell has poor support for this case. Users can
see surprising things if they try to troubleshoot merely through the
Explorer GUI.)
Received on 2013-09-29 00:20:45 CEST

This is an archived mail posted to the Subversion Dev mailing list.