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
> 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.
>> 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
>> 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
>> 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
>>>> we recently started getting this error when trying to update or
>>>> check-out a
>>>> 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?
>>>> svn: E720002: Can't move
>>>> 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to
>>>> The system cannot find the file specified.
>>>> svn: E720183: Additional errors:
>>>> svn: E720183: Can't create directory
>>>> 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
>> 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
>> ra_local then try doing it over http.
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
This email is free from viruses and malware because avast! Antivirus protection is active.
Received on 2014-01-14 07:20:36 CET