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@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
