On 02.03.2014 20:23, Stefan wrote:
> Hi Brane and Olli,
>> On 02.03.2014 11:40, Stefan wrote:
>>> Hi,
>>>
>>> I came up with an even easier repro case. It seems to suffice to
>>> trigger the problem by simply committing the problematic file to an
>>> empty local repository and having avast installed.
>>> To whom should I send the repro-case (it requires the zipped-exe-file).
>>
>> The problem is obviously caused by the virus scanner. If it's
>> renaming files from under Subversion's nose, there's really nothing
>> we can do about it.
> Well, if you are sure that the virusscanner is actually causing the
> rename, of course there's little SVN could do about. But then I'd find
> that really odd for a virus scanner and wouldn't suspect that it is
> doing that.
The name of the temporary file is a hint. Subversion creates all
temporary files with a name that begins with "svn-", followed by a
number of hex digits. The file you found has a name with a completely
different format, which reminds me of how mktemp() works on Windows.
We've seen virus scanners on Windows do all manners of silly things, so
I wouldn't be at all surprised if this one thinks mucking around with
the names of files is just fine.
> 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.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-03-02 22:04:22 CET