We use Nant to automate our builds. Everything was working fine until about a week ago when the rains caused our power to go out and the build server had to be re-booted. Now, we get the following error whenever we attempt a build:
<internalerror>
<type>System.Runtime.InteropServices.COMException</type>
<message><![CDATA[SourceSafe was unable to finish writing a file. Check your available disk space, and ask the administrator to analyze your SourceSafe database.]]></message>
<stacktrace><![CDATA[ at SourceSafeTypeLib.VSSItemClass.Get(String& Local, Int32 iFlags)
at NAnt.Contrib.Tasks.SourceSafe.GetTask.ExecuteTask()]]></stacktrace>
</internalerror>
We ran the Analyze utility on the VSS database and there appears to be plenty of room on the build server, but no luck. Any ideas? I'm at a loss.
My problem was that the current file was empty... I wrote a comment on it and everything worked ok
Ok, here is the resolution. It turns out that somehow, the version of an app.config file that was referenced in the build script was corrupted (all the previous versions, actually), which caused the VSSGet error. Updating the version to the current version fixed the errror.
I had this issue when I tried to migrate a Source Safe database to Subversion, using VSS2SVN.
This error is related to the message
There is a diff chain size mismatch in file '' (bdaaaaaa) at version (versions earlier than that version can no longer be retrieved from the database).
that may be reported by the Source Safe tool analyze.exe.
If you look into the history of the file and try to Get a version that is older than the one reported by analyze.exe, the message of this question is shown.
Microsoft provided hotfix KB927887 for cases where this was caused by XML files toggling BOM inclusion, but I did not try to apply it.
See also Message: SourceSafe was unable to finish writing a file
Related
I'm trying to figure out the root cause of a strange TFS error we are seeing in our current instance. It wasn't noticed until after a server move, but I'm not sure if they're directly related, because the error seems to be showing up for check-ins about a week prior to the move, as well as all those following it.
We first noticed the problem when I tried to get latest, and got several errors indicating:
"The downloaded file is corrupt. Please get the file again."
Upon looking into the error, we have noticed that starting as of a single check-in every code update has resulted in files being replaced with the contents of other files, ranging from project files to binary executable files (presumably assembly DLLs), rather than the expected content which is still present on our local development machines.
I don't have admin access to the servers myself, but am looking for ideas on possible causes and/or fixes for our team to investigate.
After weeks of searching, I finally found another mention of this sort of thing happening, along with a solution that appears to have worked.
Clear the Application Tier cache.
MSDN Archived Forums: TFS swapping contents of files
I recently rolled out an update for Jenkins to kick off sonar-scanner on version 5.6 of SonarQube. I'm not using the plugin, just a command line call of the sonar scanner from the directory where the sonar-project.properties file resides.
So far all of the developers have followed the same steps, and configure the properties file for their services and works great except in a few cases. Two developers have had a strange issue, when an error message prompts:
"Caused by: Not authorized. Analyzing this project requires to be authenticated. Please provide the values of the properties sonar.login and sonar.password."
I thought this to be strange because the other developers would probably have the same issue if the authentication token I used in the instructions was wrong. I compared a working copy with the version the first developer and the only difference was the project specific things such as DLL name, version, etc... I'll provide a template below. With the file looking fine, I saved off the broken copy, and copied the contents of another working copy into the broken copy. I then changed the project specific properties, and commit into subversion. Sonar scans successfully!
Out of curiosity, I then compared the old broken file and the new working copy line by line. Their was absolutely no difference between any character. I then thought this must be an encoding issue. I did a quick test by adding the sonar encoding property, commit this back and the scan failed. So I then changed back to the working copy and just continued.
The next day a second developer came to me with the same exact issue. I then tried the same previous steps where I copied the contents of a working copy, and pasted into the new, and commit this back in. However this time the workaround did not work. In fact, I tried about 5 different working copies to paste into and they all failed with that authorization error. I know the properties file is exactly correct with the token and such.
I'm not sure what to do at this point, I haven't come across any logs on the server that indicate any good information to me unless their is a log I'm unaware of.
# Token
sonar.login=SOMESECRETTOKEN
# Unique project key for sonar
sonar.projectKey=SOMESERVICE
# UI Settings for sonar
sonar.projectName=SOMESERVICE
sonar.projectVersion=SOMEVERSION
# Path to source, if not set it searches from this
# file's directory
sonar.sources=.
# Encoding of the source code. Default is default system encoding
#sonar.sourceEncoding=UTF-8
#Cop
sonar.stylecop.projectFilePath=./SOMEPROJ.csproj
sonar.cs.fxcop.assembly=./bin/Release/SOMEDLL.dll
sonar.cs.fxcop.fxCopCmdPath=C:/Program Files (x86)/Microsoft Fxcop 10.0/FxCopCmd.exe
sonar.fxcop.assemblies=./bin/Release/SOMEDLL.dll
Any helps or pointers is appreciated, thanks!
This isn't about your encoding or file contents, but about permissions. The user that runs the scan doesn't have Execute Analysis permissions on the projects in question.
And to create new projects with the first analysis, the user must also have the Create Projects permission.
When encountering this issue, I loaded the file in Notepad++ which told me the file was saved under some strange encoding visual studio gave text files. I fixed it by switched the encoding to UTF-8 which resolved the problem. This probably should be handled better in Sonar!
I'm currently attempting to fix build issues which occured once i tried to update some component. they told me i need to update some references. Oddly enough i now get these issues:
Now i'll just add some text so someone comming from google can find the potential answer as well:
error reading xamarin android.support embedded jar error in opening zip file.
Does anyone know how to fix this? I've tried:
Deleting and restoring nugetpackages, in hopes the nuget install script supplied these files,
Uninstall+Install Support Package in Android SDK Manager
Deleting files, in hope they are just temporary references and are pulled by xamarin if they are missing.
Neither one of those attempts worked out sadly.
Any ideas?
Turns out the reason of this issue was actually my own impatience. At some point after package updates i must have canceled the build process assuming that it got stuck, because it just wouldn't deploy. That resulted in incomplete jar files.
I fixed the issue by deleting the folders in AppData/Local/Xamarin which raised errors and that in turn made sure the build process redownloads the required files properly.
I am using Microsoft Visual Studio 2010. I am running code that includes several large queries accessing large amounts of data. On Friday when I debugged my code it was working properly with no errors. Upon returning today when I run the code 9 out of 10 times I get this error:
[DB2/NT64] SQL0952N Processing was cancelled due to an interrupt. SQLSTATE=57014
After doing some research into I have seen that QUERYTIMEOUTINTERVAL=0 can be added to the [Common] section in the db2cli.ini file. This will cause the CLI driver to wait for the execution of the query without timing out before returning to the application. This should resolve the problem I believe. Only problem is I cannot locate the db2cli.ini file. I am using a windows 7 operating system so I believe the file should be along this path:
C:\Program Files\IBM\SQLLIB\cfg
Only problem is when I enter the cfg file I do not see the db2cli.ini file. Any help would be greatly appreciated. Either on how to find this file and insert the querytimeoutinterval code or another way to resolve my issue. Thanks.
db2cli.ini may not exist unless you have created it previously. There is a sample file to get you started, which should be in C:\ProgramData\IBM\DB2\driver_copy_name\cfg, as indicated in the manual.
You can also avoid editing the file manually -- open the DB2 command line and issue db2 update cli cfg for section common using QueryTimeoutInterval 0 (note that the keyword QueryTimeoutInterval is case-sensitive).
Ok I have apparently caused a large problem with my companies tortoise svn program, me and the admin are in the process of trying to fix it, but were not having much luck, here is my error message:
Unable to open an ra_local session to URL
Unable to open repository 'file://file/directory/project/folder'
Berkeley DB error for filesystem '//file/directory/db' while opening
'nodes' table:
Invalid argument
bdb: file nodes (meta pgno = 0) has LSN [13005][1627022].
bdb: end of log is [13105][1531127]
bdb: \\file\directory\db\nodes: unexpected file type or format
This error occurs when i attempt to update, similar errors occur when I try to commit, or check out, also.
of course I have changed a couple of things in the error message, like the actuall directories we have here, but that is all I have changed.
the error occurred when I attempted to check something out, it then hung up, and i had to close it, then after this, it has been giving us this error.
Were running it on windows xp and the tortoise version number is 1.5.2
Our Admin tried using the svnadmin to repair the system, and when it told him it was complete it spit up a similar error once again. any one out there in tv land have any ideas what might be the problem here?
The svnadmin command line tool (not bundled with TortoiseSVN) has some subcommands to perform maintenance on the repository. You appear to be using Berkeley DB so you should also read the Berkeley DB Recovery chapter. You can download svn binaries from Slik SVN.
Update: Latest releases of TortoiseSVN already bundle svnadmin and most other useful command-line utilities, thus you no longer need Slik SVN.