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
