On 2014-03-02 11:40, Stefan wrote: > Hi, > > I came up with an even easier repro case. It seems to suffice to trigger the > problem by simply committing the problematic file to an empty local > repository and having avast installed. > To whom should I send the repro-case (it requires the zipped-exe-file). >
Hi Stefan, if it works without installed avast or with a different virus scanner installed, then I suggest to open a ticket by avast. >> >> 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 >> > >
