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" <luke1...@gmx.de> 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 >
