RE: Respecting inherited Windows file permissions on file create

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.

                Bert

From: Branko Čibej [mailto:brane_at_wandisco.com]
Sent: maandag 30 september 2013 7:26
To: Subversion Development
Cc: Jason Kresowaty
Subject: Re: Respecting inherited Windows file permissions on file create

On 29.09.2013 23:15, Ivan Zhakov wrote:

On 29 September 2013 18:49, Branko Čibej <mailto:brane_at_wandisco.com> <brane_at_wandisco.com> wrote:

On 29.09.2013 16:06, Jason Kresowaty wrote:
 
The solution Ivan mentioned of creating a temp file in the same directory as
the final file is common.
 
 
I agree this is something we can look at. There were good reasons to not
create temporary files in the target directories, but we can certainly
revisit those reasons.
 
 

Brane, do you remember reasons for creating temporary files in
.svn/tmp instead of target directory? Is it pre-wcng decision?

Ben already answered this question. I'd like to point out that this /may/ be a regression from 1.6: in the old working copy, the temporary files were created in the current directory's .svn/tmp, not in the root of the working copy. So, ACLs set on the parent were most likely inherited correctly.

There's still a way to create temporary files with the correct security attributes but without most of the problems that Ben mentioned: create the empty tempfile in the target directory, then immediately move it to <wcroot>/.svn/tmp. The final installation remains atomic, and the file will have the correct ACLs. Unfortunately, there's a short period of time when the new file is visible, two moves are of course more expensive than one, and recovery from failure is more complex.

There's another problem with this approach on Windows: unlike on Unix, you cannot rename an open file. Instead of the current open/write/close/move sequence, you'd have create/close/move/open/write/close/move, which is three more system calls. That's not cheap.

The visibility problem can be easily solved by making the initial tempfile names predictable (using a common prefix, for example).

-- Brane

-- 
Branko Čibej | Director of Subversion 
WANdisco // Non-Stop Data 
e. brane_at_wandisco.com