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
>
>
Received on 2014-03-02 11:38:59 CET