subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan <>
Subject Re: Can't move temporary on update.
Date Sun, 02 Mar 2014 10:01:34 GMT

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 
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, 
  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:

Looking at the .svn/tmp-directory I do see that a file with the expected 
file contents was created, but is named differently:

 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.


View raw message