On 03.03.2014 21:38, Stefan wrote:
> Hi,
>
> first thing: Thanks for ur support so far.
> I've spend some more hours trying to figure out what's going on there,
> but seem to be at a loss.
>
> I put together a text-file with the information gathered from Process
> Monitor limited just to the three files - svn-8F67C7E9,
> print_options.exe (the file I try to commit/update), and trzED57.tmp
> (the temp file used by Avast).
> www.luke1410.de/raw/svn_prob.txt
>
> There is nothing I can see which sets the delete for the svn-8F67C7E9.
> However there's a setting for the trzED57.tmp to delete it. Weird
> thing is that after the whole test the svn-8F67C7E9 is removed, while
> the trzED57.tmp file is still present in the directory. It looks like
> Windows removes the "wrong" file here...
Avast probably uses a kernel-level filesystem filter driver to hook into
the I/O. The Windows I/O stack architecture and environment are insanely
complex, to put it mildly. The filter driver might somehow be getting
its wires crossed and setting the delete disposition on the wrong file
control block. That would be a major bug, but a quick search shows
recent reports of other driver-related problems in Avast, so it's ...
less than impossible.
> I'll also get in touch with Avast to see what they make out of it and
> if time permits will try to set-up a simple test-scenario to see if I
> can reproduce that behavior without the virus scanner... It looks like
> the mere sequence of file operations is triggering that behavior.
You won't be able to reproduce it without the scanner ... I'm 99%
certain it's not a Windows bug.
Instead, I propose trying to reproduce this without Subversion. It's
just a tool to get the exe file onto your disk; it shouldn't be too hard
to write a small program that reproduces what svn does to the file. I
suggest using the same .exe file, but compress it on the srever (using
XZ compresion, maybe, so that Avast doesn't interpret the contents
during network transfer), then stream it from the web server through a
local XZ decompressor, and see what happens. The important bit is
probably to cerate the local target file with the same share mode. If
this "works", you end up with a nice reproduction tool for the Avast
folks. :)
You may be able to use the 7zip library for the XZ bits.
-- Brane
> On 03/03/2014 11:14, Bert Huijben wrote:
>> You would see updating of this flag as a ‘disposition’ change. On NT
>> 6.0 and later deletes and moves on Windows are at the kernel level
>> opening the file with delete access and then updating the
>> disposition. Closing and reopening via a ‘move’ is slower than doing
>> this with just one handle as the second open performs access control
>> again and might invoke other hooks as virus scanners.
>>
>> Brane: We already use the move open file (using this low level
>> disposition) on file installs in trunk, so I wouldn't call it
>> impossible. Until recently this was just hidden for applications,
>> except when you looked at this using process monitor.
>>
>> And this issue report is a nice example of showing how this approach
>> avoids problems caused by other programs (and resolves a lot of race
>> conditions on using working copies from multiple processes by having
>> proper access control around the operations).
>>
>> We could use the same pattern for installing into the pristine store,
>> but that would require updating most of our wc internal pristine
>> install logic. It would result in a performance improvement on
>> Windows though. Especially on network drives and for users of virus
>> scanners (=almost every Windows user in a corporate environment)
>>
>> Bert
>>
>> Sent from Windows Mail
>>
>> *From:* 'Stefan' <mailto:luke1410_at_gmx.de>
>> *Sent:* Monday, March 3, 2014 7:43 AM
>> *To:* Branko Čibej <mailto:brane_at_wandisco.com>,
>> users_at_subversion.apache.org <mailto:users_at_subversion.apache.org>
>>
>> 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
>> earlier:
>>
>> Upon the creation of the temp file:
>> G:\[delete]Test\checkout_TestRepo\.svn\tmp\svn-D0145269
>>
>> 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).
>>
>> Regards,
>> Stefan
>
>
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-03-04 00:53:07 CET