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. br...@wandisco.com