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.
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.
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.
Regards,
Stefan
Received on 2014-03-02 22:55:26 CET