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:31:41 GMT

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 : 

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.

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

View raw message