Hi,
I also think I found a (to the other described problem most likely
distinct) issue.
The problem occurs in a file deep in the folder structure.
Let's say it' occurs with a file located in :
Repo/trunk/A/B/C/D/E/filename.exe
When I check-out trunk let's say on G:\test and do an update on that
directory, after the failure, the working copy is locked and I have to
do an SVN cleanup before I can run another update.
However, when I do an update directly on G:\test\A\B\C\D\E, the working
directory is not locked after the error occurred.
Regards,
Stefan
> Hi,
>
> sry for the belated answer. It took me a while before I had some time
> to investigate that issue deeper.
>
> Following investigations were done with TSVN 1.8.5 (Subversion 1.8.8)
> and Server is now running Visual SVN 2.7.3 (based on SVN 1.8.5).
>
>>> 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)?
> I hope to be able to try that out later today. But no promises.
>
>> 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.
> I debugged the code directly and didn't run into the breakpoint I set
> in run_file_install().
> The code-path which returns the error seems to be somewhere else in my
> case (or did I get u wrong here).
> From what I can tell, it goes like this:
> [...]
> - svn_wc__db_pristine_install()
> - calls: svn_io_file_rename()
> - calls: svn_io_file_rename()
> - calls: apr_file_rename(from_path_apr, to_path_apr, pool);
> - calls: if (MoveFileExW(wfrompath, wtopath,
> MOVEFILE_REPLACE_EXISTING || MOVEFILE_COPY_ALLOWED))
> That one returns a status code of 720,002. If I'm reading the
> APR-macros correctly, that corresponds to a window system error of 2 -
> which according to MSDN means: ERROR_FILE_NOT_FOUND.
>
> Setting a breakpoint right before that Move-call in apr_file_rename
> suggests it's trying to move the following file:
> G:\Egosoft\X4\Source\.svn\tmp\svn-C5D6631B
> to
> G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base
>
>
> Looking at the .svn/tmp-directory I do see that a file with the
> expected file contents was created, but is named differently:
> trz5B5.tmp
>
> From that point, it's obvious that the move-call would fail, since the
> given filename seems to differ from that on the disk.
>
> Taking ur statement into account I assume that SVN tries to actually
> put a differently named file into that folder and somehow that one
> seems to get mangled on my system to a different filename.
> If so, I could try to debug the code a bit further. Would u have the
> function for me I'd investigate to trace down where the temp-file
> would be 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.
> There's nothing special from the file system set-up point of view. The
> drive is a simple local partition on an IDE drive. There are no
> symlinks or somesuch in place. File system is NTFS. The issue is
> reproducible on two different machines, both running Avast Antivirus.
> I don't know much about the set-up on the other machine, but I would
> expect it's somehow the same.
>
>>>> 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?
> No, sry, wasn't clear enough. We didn't test whether it's at all
> related to a VPN-connection. We can't atm test it without a VPN
> connection to test whether it's at all related to that. I'll try to do
> a local set-up of a working copy to see whether it's reproducible in
> that environment too. Can't tell atm when I got the time to get it
> done, but might have a few minutes left today. Let's see.
>
> Regards,
> Stefan
>
Received on 2014-03-02 11:32:23 CET