On 02.03.2014 22:54, Stefan wrote:
> 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 could provide the process monitor log, if u want to spend a few
> minutes double-checking my investigations just to make sure I didn't
> overlook anything.
I think it's more or less clear from the info you already sent that
Avast is doing something weird. I recommend reporting this issue to them.
> From what I can see, I'd guess the only way to strengthen SVN against
> this odd AV behavior would be to keep a filehandle open on the
> temp-file until it's moved into the pristine-directory.
You can't do that on Windows.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-03-03 00:57:55 CET