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...
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.
Regards,
Stefan
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
Received on 2014-03-03 21:39:04 CET