On 30.09.2013 11:33, Ivan Zhakov wrote:
> On 30 September 2013 12:12, Bert Huijben <bert_at_qqmail.nl> wrote:
>> Given the ‘create/close/move/open/write/close/move’ the average Windows
>> installation would introduce a few more steps on both open and close for
>> virusscanner intervention.
>>
>> There are thousands of regressions since moving to a central working copy
>> database, but most of them weren’t designed as features in the first place.
>> Som users just mounted parts of the working copy and used that as a working
>> copy root…
>>
>> ‘Fixing this’ without a proper design by locking a file 3 or 4 times more
>> might just make the average checkout or update 2 or 3 times slower… I would
>> call that a far more serious regression than the ACL management one that we
>> never promised to work in any particular way.
>>
>>
> Theoretically we can fix it atomic, without locking and creating file
> in target directory. Using some security descriptor magic:
> 1. Create temporary file .svn/tmp
> 2. Obtatain SECURITY_DESCRIPTOR of target directory
> 3. Convert all non-inherited permissions to inherited
> 4. Set this SECURITY_DESCRIPTOR for temporary file.
Whew. I'd really prefer not to second-guess Windows ACL inheritance like
this, especially as there's no guarantee that you can actually change
the ACL on the file that you create in .svn/tmp.
BTW, I hope it's understood that Windows isn't the only problem here;
any filesystem with ACLs will have the same issues. There are quite a
few of those around these days.
> Optionally we can specify SECURITY_DESCRIPTOR when file is being
> created, but we need direct CreateFile() for this instead of APR.
I think that's the least of our problems.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-09-30 12:08:39 CEST