On 30.09.2013 11:33, Ivan Zhakov wrote: > On 30 September 2013 12:12, Bert Huijben <b...@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. br...@wandisco.com
