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 quite obvious already just by the filename, since
it's an exe-file).
Would it be beneficial if I create an entry in ur bugtracker with that
suggestion?
Regards,
Stefan
Regards,
Stefan
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 folder I tried to check-out contains an exe-file
(print_options.exe) and that's the file the update/check-out junked on.
For me the issue has been solved. I'm just wondering whether SVN
couldn't actually either do something about that or whether at least
the presented error-message could be a bit improved. Just from the
error it was almost impossible to get the hint to a virus scanner issue.
Regards,
Stefan
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 you're trying to say the server is using http.
I traced the issue down to obvious problems with a certain
directory in the
repository. Ignoring/Skipping that directory and the check-out as
well as the
update operation work fine.
Looking into the .svn/tmp-directory I do see a single existing file:
trz2A87.tmp but obviously there's no trace of the mentioned
svn-E78ED003 file.
Can you possibly come up with a reproduction recipe that doesn't
require access
to your repo (unless of course your repo is publicly accessible)?
The errors you're getting are coming from the run_file_install()
step of the
workqueue processor. It's rather hard to understand what's going
just from the
error messages. Based on what you're saying it seems like the temp
file we're
trying to move into place doesn't exist. Since looking at the code
we try to
install the file, and then trap a ENOENT error from the rename
call. When the
rename call fails with ENOENT we try to create the destination
directory.
Which fails and thus you see the errors.
Right above the code generating the error it creates and writes the
temp file.
So I would expect to be seeing an error message from that if the
file isn't
being created.
One question I do have is have you done anything unusual with how
your file
system is setup? The .svn/tmp directory needs to be on the same
file system as
the rest of the working copy since we're doing atomic renames to put
files into
place.
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).
So same machine, same working copy doesn't work over the VPN but
does without a
VPN? Is the working copy perhaps on a network filesystem?
Error:
svn: E720002: Can't move
'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to
'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base':
The system cannot find the file specified.
svn: E720183: Additional errors:
svn: E720183: Can't create directory
'G:\Egosoft\X4\Source\.svn\pristine\00':
Cannot create a file when that file already exists.
The issue is 100% reproducible on two completely different machines.
Is there any way I could trace down the root-cause of the problem?
I think the best thing to do is try to create a minimal reproduction
recipe.
Start with create a new repo, adding files/directories needed. Try with
ra_local (file://) rather than http first. If you can't duplicate
it with
ra_local then try doing it over http.
---
This email is free from viruses and malware because avast! Antivirus
protection is active.
http://www.avast.com
---
This email is free from viruses and malware because avast! Antivirus
protection is active.
http://www.avast.com
