[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Can't move temporary on update.

From: Stefan <luke1410_at_gmx.de>
Date: Mon, 03 Mar 2014 07:43:15 +0100

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 07:43:55 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.