[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 12:19:21 -0700

> From: Ivan Zhakov <ivan_at_visualsvn.com>
> Date: Sat, September 28, 2013 2:46 pm
> 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.

I think you are describing solutions to a different (harder) problem
than I raised. You are trying to solve the case where the "disrespected"
permissions were ones that were applied directly to the file that was
later replaced by svn. My case was permissions implied by inheritance.
I think that takes a different solution. I say that yours is harder,
because the problem I described is solvable by adding a single call to
SetNamedSecurityInfo with parameters whose values are easy to determine
(i.e., mostly NULLs).

If I follow correctly, neither of your two solutions would cause my
sample reproduction code to succeed. What I would expect is defined to
be identical to what would happen if svn always recreated files from
scratch at their final location using default options, without any
filesystem "move" calls. (Whether that is, in fact, a viable option to
allow the user to configure may be another angle to consider.)

For what it is worth, it is less common to assign permissions on
individual files than to inherit them from directories. But in either
case, I think inserting the call to SetNamedSecurtyInfo is an
improvement. Users should be more understanding that the permissions
were reset to inheritance than they were copied from some hidden
place without respect to inheritance defined on the file's final
location parent directory permissions.

If I understand correctly, use of SetNamedSecurityInfo will cause the
system to behave as if the move optimization (I'm assuming it is some
kind of optimization) was not in place and that the file was instead
written from scratch with the default security parameters on Windows.
Received on 2013-09-28 21:25:00 CEST

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