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