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 have
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: Merge information lost with newer versions of subversion
On Wed, 26 Feb 2014 20:41:38 +0100 Henrik Carlqvist wrote: > Now I have finally been able to create a small case where merge > information is lost. I didn't get much response here, do you think that I should file a bug report into the subversion issue tracker? regards Henrik
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
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
Update from 1.8.5 to 1.8.8 breaks my self-signed numeric IP certificate
I recently upgraded from 1.8.5 to 1.8.8 via macports. The new version refused to permanently accept my self-signed certificate, citing an "unknown error". Certificates generated on Windows 2008 Server using VisualSVN 2.7.4. Hostname is a numeric IP on a VPN (192.168.100.59) Client is Mac OS X 10.9.1 (Mavericks) with svn installed via Macports: subversion @1.8.5_1+universal (active) < this setup works subversion @1.8.8_0+no_bdb+universal < this setup fails Under 1.8.8: $ svn update Updating '.': Error validating server certificate for 'https://192.168.100.59:443': - The certificate has an unknown error. Certificate information: - Hostname: 192.168.100.59 - Valid: from Mar 1 02:21:16 2014 GMT until Feb 27 02:21:16 2024 GMT - Issuer: - Fingerprint: BE:C4:65:B6:0E:BD:5C:EE:F4:DB:A9:E1:EB:AE:B6:BC:43:F2:E7:5E (R)eject or accept (t)emporarily? t At revision 46. Under 1.8.5 with no other changes: $ svn update Updating '.': At revision 46.
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