You would see updating of this flag as a ‘disposition’ change. On NT 6.0 and later deletes and moves on Windows are at the kernel level opening the file with delete access and then updating the disposition. Closing and reopening via a ‘move’ is slower than doing this with just one handle as the second open performs access control again and might invoke other hooks as virus scanners.
Brane: We already use the move open file (using this low level disposition) on file installs in trunk, so I wouldn't call it impossible. Until recently this was just hidden for applications, except when you looked at this using process monitor.
And this issue report is a nice example of showing how this approach avoids problems caused by other programs (and resolves a lot of race conditions on using working copies from multiple processes by having proper access control around the operations).
We could use the same pattern for installing into the pristine store, but that would require updating most of our wc internal pristine install logic. It would result in a performance improvement on Windows though. Especially on network drives and for users of virus scanners (=almost every Windows user in a corporate environment)
Bert
Sent from Windows Mail
From: 'Stefan'
Sent: Monday, March 3, 2014 7:43 AM
To: Branko Čibej, users_at_subversion.apache.org
Hi Brane,
>>>
>>>> Is there some code path I'd trace down to confirm it's actually the
>>>> virusscanner causing the rename? Where in the code path would the
>>>> tmp-file be generated?
>>> The call stack is probably:
>>> svn_io_open_unique_file3
>>> svn_stream_open_unique
>>> ....
>>> svn_wc__open_writable_base
>>> ...
>>> apply_textdelta
>>>
>>> The last function is private to subversion/libsvn_wc/update_editor.c.
>> Thanks that helped. I traced it down and it looks like when SVN is
>> closing the stream to write the temp file, it gets removed from disk.
>> I tried to trace the issue down a bit further using Process Monitor
>> as suggested by Thorsten but am a bit buffled by the log. It seems to
>> have no record of either a rename-operation or a delete operation on
>> svn-BDF57639. A query on the file from the Avast succeeds while an
>> almost directly following query on the same file from TSVN fails.
>
> Heh. I wonder if Avast is setting the delete-on-close flag on
> Subversion's temp file. That would explain why it suddenly disappears.
> Subversion definitely isn't doing that in this particular case; note
> the svn_io_file_del_none parameter used in svn_wc__open_writable_base.
I can't see in the Process Monitor that Avast is actually setting that
flag. Actually I don't see anyone setting that flag. But that idea let
me to review the case, and I spotted an attribute which I overlooked
earlier:
Upon the creation of the temp file:
G:\[delete]Test\checkout_TestRepo\.svn\tmp\svn-D0145269
Desired Access: Generic Read/Write
Disposition: Create
Options: Synchronous IO Non-Alert, Non-Directory File
Attributes: n/a
ShareMode: Read, Write, Delete
AllocationSize: 0
OpenResult: Created
ShareMode Delete... That made me a bit suspicious here. Why should SVN
create that file with the share mode set to delete? Doesn't that suggest
that any other process would be allowed to change the delete-state of
that file while the handle is open? I don't know whether this is related
to the problem or not, but I'm wondering the reasoning for that (or am I
misreading that parameter --- i'm not that much into Windows file
handling tbh).
Regards,
Stefan
Received on 2014-03-03 11:27:57 CET