Re: Can't move temporary on update.

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