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
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
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
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" w
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
On 02.03.2014 22:54, 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
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
Hi Thorsten,
and wouldn't suspect that it is doing that.
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 thetmp-file
be generated?
I would first try to use Process Monitor to see activity in the file
system,
On 02.03.2014 20:23, Stefan wrote:
> Hi Brane and Olli,
>> On 02.03.2014 11:40, Stefan wrote:
>>> Hi,
>>>
>>> I came up with an even easier repro case. It seems to suffice to
>>> trigger the problem by simply committing the problematic file to an
>>> empty local repository and having avast installe
Guten Tag Stefan,
am Sonntag, 2. März 2014 um 20:23 schrieben Sie:
> Well, if you are sure that the virusscanner is actually causing the
> rename, of course there's little SVN could do about. But then I'd
> find that really odd for a virus scanner[...]
Wouldn't be the first "odd" thing about s
Hi Brane and Olli,
On 02.03.2014 11:40, Stefan wrote:
Hi,
I came up with an even easier repro case. It seems to suffice to
trigger the problem by simply committing the problematic file to an
empty local repository and having avast installed.
To whom should I send the repro-case (it requires
On 02.03.2014 11:40, Stefan wrote:
> Hi,
>
> I came up with an even easier repro case. It seems to suffice to
> trigger the problem by simply committing the problematic file to an
> empty local repository and having avast installed.
> To whom should I send the repro-case (it requires the zipped-exe
On 2014-03-02 11:40, Stefan wrote:
> Hi,
>
> I came up with an even easier repro case. It seems to suffice to trigger the
> problem by simply committing the problematic file to an empty local
> repository and having avast installed.
> To whom should I send the repro-case (it requires the zipped-
Hi,
I came up with an even easier repro case. It seems to suffice to trigger
the problem by simply committing the problematic file to an empty local
repository and having avast installed.
To whom should I send the repro-case (it requires the zipped-exe-file).
Regards,
Stefan
Hi,
sry for the
Hi,
It would have also been quite useful to get the filename of that file
that SVN tried to copy the temporary for. If it would have stated
"print_options.exe", we could have run a bit of testing just with that
one file to easier trace it down to an anti virus related problem
(would have been
Hi,
I also think I found a (to the other described problem most likely
distinct) issue.
The problem occurs in a file deep in the folder structure.
Let's say it' occurs with a file located in :
Repo/trunk/A/B/C/D/E/filename.exe
When I check-out trunk let's say on G:\test and do an update on t
Hi,
sry for the belated answer. It took me a while before I had some time to
investigate that issue deeper.
Following investigations were done with TSVN 1.8.5 (Subversion 1.8.8)
and Server is now running Visual SVN 2.7.3 (based on SVN 1.8.5).
I traced the issue down to obvious problems wit
Does your virus scanner (local or on the server if G: is a network drive) do
something specific with that file? It appears that the tempfile that was just
created, disappeared before it could be moved into the pristine store.
Bert
Sent from Windows Mail
From: Stefan
Sent: Monday, Ja
It would have also been quite useful to get the filename of that file
that SVN tried to copy the temporary for. If it would have stated
"print_options.exe", we could have run a bit of testing just with that
one file to easier trace it down to an anti virus related problem (would
have been quite
Hi,
thanks for the hints. I obviously mixed-up the thing with serf/neon.
Yes, the connection is via http.
Actually ur hints let me thinking it might be an access issue on my
machine and it turns out that when I disable my virus scanner,
everything works just fine (using avast! here).
The f
On 1/13/14, 1:32 PM, Stefan wrote:
> Sry, forgot the obvious most important info:
>
> Client is running 1.8.5
> Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up
> to
> use neon.
FYI, the server doesn't use neon. Neon or Serf is only used on the client.
I'm guessing y
Sry, forgot the obvious most important info:
Client is running 1.8.5
Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is
set-up to use neon.
I traced the issue down to obvious problems with a certain directory in
the repository. Ignoring/Skipping that directory and the check
Hi,
we recently started getting this error when trying to update or
check-out a repository.
Weird thing is that the issue only occurs when we try to
check-out/update the thing externally (meaning via VPN).
Error:
svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to
'G:\Eg
23 matches
Mail list logo
