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:br...@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:br...@wandisco.com>
<br...@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. br...@wandisco.com
