RE: Respecting inherited Windows file permissions on file create
From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 30 Sep 2013 10:12:26 +0200
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.
From: Branko Čibej [mailto:brane_at_wandisco.com]
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:
Brane, do you remember reasons for creating temporary files in
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).
-- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. brane_at_wandisco.comReceived on 2013-09-30 10:17:25 CEST
This is an archived mail posted to the Subversion Dev mailing list.