subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bert Huijben <b...@qqmail.nl>
Subject Re: Can't move temporary on update.
Date Mon, 03 Mar 2014 10:14:54 GMT
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
Mime
View raw message