Re: Can't move temporary on update.
You would see updating of this flag as a ‘disposition’ change. On NT 6.0 and later deletes and moves on Windows are at the kernel level opening the file with delete access and then updating the disposition. Closing and reopening via a ‘move’ is slower than doing this with just one handle as the second open performs access control again and might invoke other hooks as virus scanners. Brane: We already use the move open file (using this low level disposition) on file installs in trunk, so I wouldn't call it impossible. Until recently this was just hidden for applications, except when you looked at this using process monitor. And this issue report is a nice example of showing how this approach avoids problems caused by other programs (and resolves a lot of race conditions on using working copies from multiple processes by having proper access control around the operations). We could use the same pattern for installing into the pristine store, but that would require updating most of our wc internal pristine install logic. It would result in a performance improvement on Windows though. Especially on network drives and for users of virus scanners (=almost every Windows user in a corporate environment) Bert Sent from Windows Mail From: 'Stefan' Sent: Monday, March 3, 2014 7:43 AM To: Branko Čibej, users@subversion.apache.org Hi Brane, Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would the tmp-file be generated? The call stack is probably: svn_io_open_unique_file3 svn_stream_open_unique svn_wc__open_writable_base ... apply_textdelta The last function is private to subversion/libsvn_wc/update_editor.c. Thanks that helped. I traced it down and it looks like when SVN is closing the stream to write the temp file, it gets removed from disk. I tried to trace the issue down a bit further using Process Monitor as suggested by Thorsten but am a bit buffled by the log. It seems to have no record of either a rename-operation or a delete operation on svn-BDF57639. A query on the file from the Avast succeeds while an almost directly following query on the same file from TSVN fails. Heh. I wonder if Avast is setting the delete-on-close flag on Subversion's temp file. That would explain why it suddenly disappears. Subversion definitely isn't doing that in this particular case; note the svn_io_file_del_none parameter used in svn_wc__open_writable_base. I can't see in the Process Monitor that Avast is actually setting that flag. Actually I don't see anyone setting that flag. But that idea let me to review the case, and I spotted an attribute which I overlooked earlier: Upon the creation of the temp file: G:\[delete]Test\checkout_TestRepo\.svn\tmp\svn-D0145269 Desired Access:Generic Read/Write Disposition:Create Options:Synchronous IO Non-Alert, Non-Directory File Attributes:n/a ShareMode:Read, Write, Delete AllocationSize:0 OpenResult:Created ShareMode Delete... That made me a bit suspicious here. Why should SVN create that file with the share mode set to delete? Doesn't that suggest that any other process would be allowed to change the delete-state of that file while the handle is open? I don't know whether this is related to the problem or not, but I'm wondering the reasoning for that (or am I misreading that parameter --- i'm not that much into Windows file handling tbh). Regards, Stefan
Re: Can't move temporary on update.
Hi, first thing: Thanks for ur support so far. I've spend some more hours trying to figure out what's going on there, but seem to be at a loss. I put together a text-file with the information gathered from Process Monitor limited just to the three files - svn-8F67C7E9, print_options.exe (the file I try to commit/update), and trzED57.tmp (the temp file used by Avast). www.luke1410.de/raw/svn_prob.txt There is nothing I can see which sets the delete for the svn-8F67C7E9. However there's a setting for the trzED57.tmp to delete it. Weird thing is that after the whole test the svn-8F67C7E9 is removed, while the trzED57.tmp file is still present in the directory. It looks like Windows removes the wrong file here... I'll also get in touch with Avast to see what they make out of it and if time permits will try to set-up a simple test-scenario to see if I can reproduce that behavior without the virus scanner... It looks like the mere sequence of file operations is triggering that behavior. Regards, Stefan On 03/03/2014 11:14, Bert Huijben wrote: You would see updating of this flag as a ‘disposition’ change. On NT 6.0 and later deletes and moves on Windows are at the kernel level opening the file with delete access and then updating the disposition. Closing and reopening via a ‘move’ is slower than doing this with just one handle as the second open performs access control again and might invoke other hooks as virus scanners. Brane: We already use the move open file (using this low level disposition) on file installs in trunk, so I wouldn't call it impossible. Until recently this was just hidden for applications, except when you looked at this using process monitor. And this issue report is a nice example of showing how this approach avoids problems caused by other programs (and resolves a lot of race conditions on using working copies from multiple processes by having proper access control around the operations). We could use the same pattern for installing into the pristine store, but that would require updating most of our wc internal pristine install logic. It would result in a performance improvement on Windows though. Especially on network drives and for users of virus scanners (=almost every Windows user in a corporate environment) Bert Sent from Windows Mail *From:* 'Stefan' mailto:luke1...@gmx.de *Sent:* Monday, March 3, 2014 7:43 AM *To:* Branko Čibej mailto:br...@wandisco.com, users@subversion.apache.org mailto:users@subversion.apache.org Hi Brane, Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would the tmp-file be generated? The call stack is probably: svn_io_open_unique_file3 svn_stream_open_unique svn_wc__open_writable_base ... apply_textdelta The last function is private to subversion/libsvn_wc/update_editor.c. Thanks that helped. I traced it down and it looks like when SVN is closing the stream to write the temp file, it gets removed from disk. I tried to trace the issue down a bit further using Process Monitor as suggested by Thorsten but am a bit buffled by the log. It seems to have no record of either a rename-operation or a delete operation on svn-BDF57639. A query on the file from the Avast succeeds while an almost directly following query on the same file from TSVN fails. Heh. I wonder if Avast is setting the delete-on-close flag on Subversion's temp file. That would explain why it suddenly disappears. Subversion definitely isn't doing that in this particular case; note the svn_io_file_del_none parameter used in svn_wc__open_writable_base. I can't see in the Process Monitor that Avast is actually setting that flag. Actually I don't see anyone setting that flag. But that idea let me to review the case, and I spotted an attribute which I overlooked earlier: Upon the creation of the temp file: G:\[delete]Test\checkout_TestRepo\.svn\tmp\svn-D0145269 Desired Access:Generic Read/Write Disposition:Create Options:Synchronous IO Non-Alert, Non-Directory File Attributes:n/a ShareMode:Read, Write, Delete AllocationSize:0 OpenResult:Created ShareMode Delete... That made me a bit suspicious here. Why should SVN create that file with the share mode set to delete? Doesn't that suggest that any other process would be allowed to change the delete-state of that file while the handle is open? I don't know whether this is related to the problem or not, but I'm wondering the reasoning for that (or am I misreading that parameter --- i'm not that much into Windows file handling tbh). Regards, Stefan
Re: Can't move temporary on update.
On 03.03.2014 21:38, Stefan wrote: Hi, first thing: Thanks for ur support so far. I've spend some more hours trying to figure out what's going on there, but seem to be at a loss. I put together a text-file with the information gathered from Process Monitor limited just to the three files - svn-8F67C7E9, print_options.exe (the file I try to commit/update), and trzED57.tmp (the temp file used by Avast). www.luke1410.de/raw/svn_prob.txt There is nothing I can see which sets the delete for the svn-8F67C7E9. However there's a setting for the trzED57.tmp to delete it. Weird thing is that after the whole test the svn-8F67C7E9 is removed, while the trzED57.tmp file is still present in the directory. It looks like Windows removes the wrong file here... Avast probably uses a kernel-level filesystem filter driver to hook into the I/O. The Windows I/O stack architecture and environment are insanely complex, to put it mildly. The filter driver might somehow be getting its wires crossed and setting the delete disposition on the wrong file control block. That would be a major bug, but a quick search shows recent reports of other driver-related problems in Avast, so it's ... less than impossible. I'll also get in touch with Avast to see what they make out of it and if time permits will try to set-up a simple test-scenario to see if I can reproduce that behavior without the virus scanner... It looks like the mere sequence of file operations is triggering that behavior. You won't be able to reproduce it without the scanner ... I'm 99% certain it's not a Windows bug. Instead, I propose trying to reproduce this without Subversion. It's just a tool to get the exe file onto your disk; it shouldn't be too hard to write a small program that reproduces what svn does to the file. I suggest using the same .exe file, but compress it on the srever (using XZ compresion, maybe, so that Avast doesn't interpret the contents during network transfer), then stream it from the web server through a local XZ decompressor, and see what happens. The important bit is probably to cerate the local target file with the same share mode. If this works, you end up with a nice reproduction tool for the Avast folks. :) You may be able to use the 7zip library for the XZ bits. -- Brane On 03/03/2014 11:14, Bert Huijben wrote: You would see updating of this flag as a ‘disposition’ change. On NT 6.0 and later deletes and moves on Windows are at the kernel level opening the file with delete access and then updating the disposition. Closing and reopening via a ‘move’ is slower than doing this with just one handle as the second open performs access control again and might invoke other hooks as virus scanners. Brane: We already use the move open file (using this low level disposition) on file installs in trunk, so I wouldn't call it impossible. Until recently this was just hidden for applications, except when you looked at this using process monitor. And this issue report is a nice example of showing how this approach avoids problems caused by other programs (and resolves a lot of race conditions on using working copies from multiple processes by having proper access control around the operations). We could use the same pattern for installing into the pristine store, but that would require updating most of our wc internal pristine install logic. It would result in a performance improvement on Windows though. Especially on network drives and for users of virus scanners (=almost every Windows user in a corporate environment) Bert Sent from Windows Mail *From:* 'Stefan' mailto:luke1...@gmx.de *Sent:* Monday, March 3, 2014 7:43 AM *To:* Branko Čibej mailto:br...@wandisco.com, users@subversion.apache.org mailto:users@subversion.apache.org Hi Brane, Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would the tmp-file be generated? The call stack is probably: svn_io_open_unique_file3 svn_stream_open_unique svn_wc__open_writable_base ... apply_textdelta The last function is private to subversion/libsvn_wc/update_editor.c. Thanks that helped. I traced it down and it looks like when SVN is closing the stream to write the temp file, it gets removed from disk. I tried to trace the issue down a bit further using Process Monitor as suggested by Thorsten but am a bit buffled by the log. It seems to have no record of either a rename-operation or a delete operation on svn-BDF57639. A query on the file from the Avast succeeds while an almost directly following query on the same file from TSVN fails. Heh. I wonder if Avast is setting the delete-on-close flag on Subversion's temp file. That would explain why it suddenly disappears. Subversion definitely isn't doing that in this particular case; note the svn_io_file_del_none parameter used in
Re: Can't move temporary on update.
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
Re: Can't move temporary on update.
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
Re: Can't move temporary on update.
Hi, It would have also been quite useful to get the filename of that file that SVN tried to copy the temporary for. If it would have stated print_options.exe, we could have run a bit of testing just with that one file to easier trace it down to an anti virus related problem (would have been quite obvious already just by the filename, since it's an exe-file). Would it be beneficial if I create an entry in ur bugtracker with that suggestion? Regards, Stefan Regards, Stefan Hi, thanks for the hints. I obviously mixed-up the thing with serf/neon. Yes, the connection is via http. Actually ur hints let me thinking it might be an access issue on my machine and it turns out that when I disable my virus scanner, everything works just fine (using avast! here). The folder I tried to check-out contains an exe-file (print_options.exe) and that's the file the update/check-out junked on. For me the issue has been solved. I'm just wondering whether SVN couldn't actually either do something about that or whether at least the presented error-message could be a bit improved. Just from the error it was almost impossible to get the hint to a virus scanner issue. Regards, Stefan On 1/13/14, 1:32 PM, Stefan wrote: Sry, forgot the obvious most important info: Client is running 1.8.5 Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up to use neon. FYI, the server doesn't use neon. Neon or Serf is only used on the client. I'm guessing you're trying to say the server is using http. 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)? 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. 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. 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? Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? I think the best thing to do is try to create a minimal reproduction recipe. Start with create a new repo, adding files/directories needed. Try with ra_local (file://) rather than http first. If you can't duplicate it with ra_local then try doing it over http. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Can't move temporary on update.
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). 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
Re: Can't move temporary on update.
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
Re: Can't move temporary on update.
On 02.03.2014 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). The problem is obviously caused by the virus scanner. If it's renaming files from under Subversion's nose, there's really nothing we can do about it. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Can't move temporary on update.
Hi Brane and Olli, On 02.03.2014 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). The problem is obviously caused by the virus scanner. If it's renaming files from under Subversion's nose, there's really nothing we can do about it. Well, if you are sure that the virusscanner is actually causing the rename, of course there's little SVN could do about. But then I'd find that really odd for a virus scanner and wouldn't suspect that it is doing that. Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would the tmp-file be generated? Regards, Stefan
Re: Can't move temporary on update.
Guten Tag Stefan, am Sonntag, 2. März 2014 um 20:23 schrieben Sie: Well, if you are sure that the virusscanner is actually causing the rename, of course there's little SVN could do about. But then I'd find that really odd for a virus scanner[...] Wouldn't be the first odd thing about such software. ;-) and wouldn't suspect that it is doing that. Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would thetmp-file be generated? I would first try to use Process Monitor to see activity in the file system, one time with and the other time without Avast or in the latter case at least with your working copy excluded for Avast. The MoveFileEx error should be easy to find using ERROR_FILE_NOT_FOUND and from that point you just need to scroll upwards to see if files are renamed by Avast or such. Avast will surely not modify Subversions code, but hook Windows functions instead and that may be hard to debug. I found Process Monitor really helpful in such cases, that's what it's designed for. http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Can't move temporary on update.
On 02.03.2014 20:23, Stefan wrote: Hi Brane and Olli, On 02.03.2014 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). The problem is obviously caused by the virus scanner. If it's renaming files from under Subversion's nose, there's really nothing we can do about it. Well, if you are sure that the virusscanner is actually causing the rename, of course there's little SVN could do about. But then I'd find that really odd for a virus scanner and wouldn't suspect that it is doing that. The name of the temporary file is a hint. Subversion creates all temporary files with a name that begins with svn-, followed by a number of hex digits. The file you found has a name with a completely different format, which reminds me of how mktemp() works on Windows. We've seen virus scanners on Windows do all manners of silly things, so I wouldn't be at all surprised if this one thinks mucking around with the names of files is just fine. Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would the tmp-file be generated? The call stack is probably: svn_io_open_unique_file3 svn_stream_open_unique svn_wc__open_writable_base ... apply_textdelta The last function is private to subversion/libsvn_wc/update_editor.c. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Can't move temporary on update.
Hi Thorsten, and wouldn't suspect that it is doing that. Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would thetmp-file be generated? I would first try to use Process Monitor to see activity in the file system, one time with and the other time without Avast or in the latter case at least with your working copy excluded for Avast. The MoveFileEx error should be easy to find using ERROR_FILE_NOT_FOUND and from that point you just need to scroll upwards to see if files are renamed by Avast or such. Avast will surely not modify Subversions code, but hook Windows functions instead and that may be hard to debug. I found Process Monitor really helpful in such cases, that's what it's designed for. http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx Mit freundlichen Grüßen, Thorsten Schöning Should have thought about using process monitor earlier... Thanks for the hint. However, I'm not getting much out there. Here's the summary from what I see in process manager from the svn-BDF57639 temp file and the corresponding trzBF17.tmp-file which in-deed is created by Avast. The problem is I don't see where the svn-BDF57639-file would be renamed or deleted. I'd gladly send the log captured with Process Monitor just to make sure I didn't overlook anything. Quick sum-up of the log: TortoiseSVN creates the file: .svn\tmp\svn-BDF57639 (SUCCESS) - Generic Read/Write access - create [...] TortoiseSVN reads the file contest of the problematic exe file: print_options.exe [...] TortoiseSVN writes the contest of that file excluding the final junk to svn-BDF57639 TortoiseSVN reads the file contents of the problematic print_options.exe-file again (EOF) [...] TortoiseSVN writes the last junk of the svn-BDF57639 file and closes the file [...] Avast creates file access to svn-BDF57639 - Read Attributes/Synchronize, Open Avast queries name information file on svn-BDF57639 Avast closes the svn-BDF57639 file Avast creates file access to svn-BDF57639 - Read Attributes, Open Avast operation: FileSystemControl - Control: FSCTL READ FILE USN DATA on svn-BDF57639 Avast closes the svn-BDF57639 file [...] Avast creates file .svn/tmp/trzBF17.tmp and closes it directly - Generic Read, Create Avast creates file access on .svn/tmp/trzBF17.tmp - Read Attributes/Delete, Open Avast queries attribute tag file - Attributes: ANCI, Reparse Tag: 0x0 on trzBF17.tmp-file Avast sets disposition information file on trzBF17.tmp - Delete: True Avast closes file access to trzBF17.tmp [...] Avast queries directory information on .svn/tmp - svn-BDF57639 is returned as existing [...] Avast queries tries to open trzBF17.tmp - file not found is returned Avast recreates the trzBF17.tmp file and writes a junk of 81.920 bytes (size of the actual print_options.exe-file) [...] Avast queries tmp-directory for svn-BDF57639 - file exists TortoiseSVN closes file access to print_options.exe [...] TortoiseSVN tries to open .svn/tmp/svn-BDF57639 - NAME NOT FOUND Regards, Stefan
Re: Can't move temporary on update.
Hi Brane, Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would the tmp-file be generated? The call stack is probably: svn_io_open_unique_file3 svn_stream_open_unique svn_wc__open_writable_base ... apply_textdelta The last function is private to subversion/libsvn_wc/update_editor.c. Thanks that helped. I traced it down and it looks like when SVN is closing the stream to write the temp file, it gets removed from disk. I tried to trace the issue down a bit further using Process Monitor as suggested by Thorsten but am a bit buffled by the log. It seems to have no record of either a rename-operation or a delete operation on svn-BDF57639. A query on the file from the Avast succeeds while an almost directly following query on the same file from TSVN fails. I could provide the process monitor log, if u want to spend a few minutes double-checking my investigations just to make sure I didn't overlook anything. From what I can see, I'd guess the only way to strengthen SVN against this odd AV behavior would be to keep a filehandle open on the temp-file until it's moved into the pristine-directory. Regards, Stefan
Re: Can't move temporary on update.
On 02.03.2014 22:54, Stefan wrote: Hi Brane, Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would the tmp-file be generated? The call stack is probably: svn_io_open_unique_file3 svn_stream_open_unique svn_wc__open_writable_base ... apply_textdelta The last function is private to subversion/libsvn_wc/update_editor.c. Thanks that helped. I traced it down and it looks like when SVN is closing the stream to write the temp file, it gets removed from disk. I tried to trace the issue down a bit further using Process Monitor as suggested by Thorsten but am a bit buffled by the log. It seems to have no record of either a rename-operation or a delete operation on svn-BDF57639. A query on the file from the Avast succeeds while an almost directly following query on the same file from TSVN fails. Heh. I wonder if Avast is setting the delete-on-close flag on Subversion's temp file. That would explain why it suddenly disappears. Subversion definitely isn't doing that in this particular case; note the svn_io_file_del_none parameter used in svn_wc__open_writable_base. I could provide the process monitor log, if u want to spend a few minutes double-checking my investigations just to make sure I didn't overlook anything. I think it's more or less clear from the info you already sent that Avast is doing something weird. I recommend reporting this issue to them. From what I can see, I'd guess the only way to strengthen SVN against this odd AV behavior would be to keep a filehandle open on the temp-file until it's moved into the pristine-directory. You can't do that on Windows. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Can't move temporary on update.
Hi Brane, Is there some code path I'd trace down to confirm it's actually the virusscanner causing the rename? Where in the code path would the tmp-file be generated? The call stack is probably: svn_io_open_unique_file3 svn_stream_open_unique svn_wc__open_writable_base ... apply_textdelta The last function is private to subversion/libsvn_wc/update_editor.c. Thanks that helped. I traced it down and it looks like when SVN is closing the stream to write the temp file, it gets removed from disk. I tried to trace the issue down a bit further using Process Monitor as suggested by Thorsten but am a bit buffled by the log. It seems to have no record of either a rename-operation or a delete operation on svn-BDF57639. A query on the file from the Avast succeeds while an almost directly following query on the same file from TSVN fails. Heh. I wonder if Avast is setting the delete-on-close flag on Subversion's temp file. That would explain why it suddenly disappears. Subversion definitely isn't doing that in this particular case; note the svn_io_file_del_none parameter used in svn_wc__open_writable_base. I can't see in the Process Monitor that Avast is actually setting that flag. Actually I don't see anyone setting that flag. But that idea let me to review the case, and I spotted an attribute which I overlooked earlier: Upon the creation of the temp file: G:\[delete]Test\checkout_TestRepo\.svn\tmp\svn-D0145269 Desired Access:Generic Read/Write Disposition:Create Options:Synchronous IO Non-Alert, Non-Directory File Attributes:n/a ShareMode:Read, Write, Delete AllocationSize:0 OpenResult:Created ShareMode Delete... That made me a bit suspicious here. Why should SVN create that file with the share mode set to delete? Doesn't that suggest that any other process would be allowed to change the delete-state of that file while the handle is open? I don't know whether this is related to the problem or not, but I'm wondering the reasoning for that (or am I misreading that parameter --- i'm not that much into Windows file handling tbh). Regards, Stefan
Re: Can't move temporary on update.
Does your virus scanner (local or on the server if G: is a network drive) do something specific with that file? It appears that the tempfile that was just created, disappeared before it could be moved into the pristine store. Bert Sent from Windows Mail From: Stefan Sent: Monday, January 13, 2014 10:32 PM To: users@subversion.apache.org Sry, forgot the obvious most important info: Client is running 1.8.5 Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up to use neon. 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. Regards, Stefan Hi, 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). Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? Regards, Stefan --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Can't move temporary on update.
Hi, 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). Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? Regards, Stefan --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Can't move temporary on update.
Sry, forgot the obvious most important info: Client is running 1.8.5 Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up to use neon. 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. Regards, Stefan Hi, 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). Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? Regards, Stefan --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Can't move temporary on update.
Hi, thanks for the hints. I obviously mixed-up the thing with serf/neon. Yes, the connection is via http. Actually ur hints let me thinking it might be an access issue on my machine and it turns out that when I disable my virus scanner, everything works just fine (using avast! here). The folder I tried to check-out contains an exe-file (print_options.exe) and that's the file the update/check-out junked on. For me the issue has been solved. I'm just wondering whether SVN couldn't actually either do something about that or whether at least the presented error-message could be a bit improved. Just from the error it was almost impossible to get the hint to a virus scanner issue. Regards, Stefan On 1/13/14, 1:32 PM, Stefan wrote: Sry, forgot the obvious most important info: Client is running 1.8.5 Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up to use neon. FYI, the server doesn't use neon. Neon or Serf is only used on the client. I'm guessing you're trying to say the server is using http. 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)? 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. 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. 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? Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? I think the best thing to do is try to create a minimal reproduction recipe. Start with create a new repo, adding files/directories needed. Try with ra_local (file://) rather than http first. If you can't duplicate it with ra_local then try doing it over http. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Can't move temporary on update.
It would have also been quite useful to get the filename of that file that SVN tried to copy the temporary for. If it would have stated print_options.exe, we could have run a bit of testing just with that one file to easier trace it down to an anti virus related problem (would have been quite obvious already just by the filename, since it's an exe-file). Regards, Stefan Hi, thanks for the hints. I obviously mixed-up the thing with serf/neon. Yes, the connection is via http. Actually ur hints let me thinking it might be an access issue on my machine and it turns out that when I disable my virus scanner, everything works just fine (using avast! here). The folder I tried to check-out contains an exe-file (print_options.exe) and that's the file the update/check-out junked on. For me the issue has been solved. I'm just wondering whether SVN couldn't actually either do something about that or whether at least the presented error-message could be a bit improved. Just from the error it was almost impossible to get the hint to a virus scanner issue. Regards, Stefan On 1/13/14, 1:32 PM, Stefan wrote: Sry, forgot the obvious most important info: Client is running 1.8.5 Server is running Visual SVN 2.5.15 - based on SVN 1.7.13 - server is set-up to use neon. FYI, the server doesn't use neon. Neon or Serf is only used on the client. I'm guessing you're trying to say the server is using http. 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)? 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. 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. 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? Error: svn: E720002: Can't move 'G:\Egosoft\X4\Source\.svn\tmp\svn-E78ED003' to 'G:\Egosoft\X4\Source\.svn\pristine\00\0077903324a83da0419971daeb632ff51529d320.svn-base': The system cannot find the file specified. svn: E720183: Additional errors: svn: E720183: Can't create directory 'G:\Egosoft\X4\Source\.svn\pristine\00': Cannot create a file when that file already exists. The issue is 100% reproducible on two completely different machines. Is there any way I could trace down the root-cause of the problem? I think the best thing to do is try to create a minimal reproduction recipe. Start with create a new repo, adding files/directories needed. Try with ra_local (file://) rather than http first. If you can't duplicate it with ra_local then try doing it over http. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
