subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan <>
Subject Re: Can't move temporary on update.
Date Mon, 03 Mar 2014 06:43:15 GMT
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 

Upon the creation of the temp file:

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).


View raw message