subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: Can't move temporary on update.
Date Mon, 03 Mar 2014 10:08:53 GMT
The share mode is the default from APR; presumably to make the default
behaviour similar to POSIX. That doesn't really matter: no other process
should be deleting Subversion's temp files. Unless it's malware ... or it's
quarantining an infected executable.

-- Brane
On 3 Mar 2014 07:43, "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 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

View raw message