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
