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.
Related
I have a project that I am building using cygwin as an env. This weekend, I tried to do a standard git pull, one that has worked hundreds of times before, and I get this message.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
/usr/bin/ssh.exe: error while loading shared libraries: cygssp-0.dll: cannot open shared object file: No such file or directory
I'm a bit confused since this has never happened before. I googled "cygssp-0.dll" and found that it is some .dll file, specifically I looked here.
I tried the first option, and got to this step
enter "regsvr32 /u cygssp-0.dll" in the command line
and I got the message
The module "cygssp-0.dll" failed to load.
Make sure the binary is stored at the specific path or debug it to check for problems with the binary or dependent .DLL files.
The specific module could not be found.
At this point, I am thoroughly confused, and not all too keen to start reinstalling windows just yet. I've tried re installing cygwin.. does anybody have any ideas on what to do?
EDIT : I have already attempted to run setup-x86_64.exe several times, in an attempt to re-install something from the cygwin side.
Turn your antivirus off of silent mode or turn off heuristics. It's just deleting the file without telling you. libssp is getting deleted because it's a security library that does things to the call stack that antivirus programs don't like. (Specifically, it adds canaries, random values inserted into the stack that are meant to guard against some buffer overflow attacks. However, an antivirus that isn't coded to handle stack canary insertion will see it as a buffer overflow attack itself.)
Had the same issue today while trying to do push via Cygwin's git via ssh.
The solution is to reinstall or update Cygwin, as missing library will be redownloaded and put in proper place. Be sure that your antivirus software isn't removing it again, so disable everything that might delete it, and/or whitelist cygssp-0.dll location. As of today they're located under:
cygwin_root\bin\cygssp-0.dll
cygwin_root\usr\i686-pc-cygwin\sys-root\usr\bin\cygssp-0.dll
(second path only for 64 bit distribution of Cygwin)
I newly started working on Github via their native Windows Application, it's quite good however it's crashing so often and the horrible thing is that I lose all the recent changes after it's crashing. All the local files will rollback to the last version of the successful commit or sync.
I'm on a 64bit windows 8 machine. Any ideas?
The exact error after crash is Couldn't find a HEAD in this repository
I sent an email to GitHub For Windows support. Their answer was this:
Hi David,
I am sorry for the trouble.
I have been able to reproduce this problem, and have filed a report for our developers to look at. The reason the application is crashing is likely due to merge conflicts between the local and remote repositories.
The easiest way to resolve this would be to go into the repository that is saying 'failed looking for HEAD', closing that pop-up, and clicking Tools -> Open a Shell Here.
From the shell, you can run 'git reset --merge' to undo the merge that caused GitHub for Windows to crash.
From there, run 'git checkout master' to switch from the detached HEAD.
After that, run 'git pull' in the shell to pull down any new changes. It will prompt you to fix any merge conflicts (which is what caused the app to crash).
Once you fix the merge conflicts in the files, you should then be able to sync correctly in GitHub for WIndows.
I have been testing this issue, and after I resolved the conflicts with the initial crash, I no longer had any further trouble with GitHub for Windows. It correctly prompted me to open the shell and resolve merge conflicts rather than crashing.
Let me know if you have any further questions, and hopefully we will have a fix out for this soon.
Best,
Steve
This is the solution I received from Github support. I'll copy & paste the exact text here:
The easiest way to resolve this would be to go into the repository that is saying 'failed looking for HEAD', closing that pop-up, and clicking Tools -> Open a Shell Here. From the shell, you can run 'git reset --merge' to undo the merge that caused GitHub for Windows to crash. After that, run 'git pull' in the shell to pull down any changes. It will prompt you to fix any merge conflicts. Once you fix the merge conflicts in the files, you should then be able to sync correctly in GitHub for WIndows.
I have been testing this issue, and after I resolved the conflicts with the initial crash, I no longer had any further trouble with GitHub for Windows. It correctly prompted me to open the shell and resolve merge conflicts rather than crashing.
I had this problem after I made an unstable change to my .gitconfig user file.
I only detected the issue after I tried using TortoiseGIT and it outlined the error parsting the config file with an unexpected token.
So the fix was to correct the bad .gitconfig file.
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
Every time I try to check out an "Out Of Date" file, I receive the following error: "Error during file delta checkout". If I delete the file in my working directory, the file now appears to be "missing" in the StarTeam client and I can do a check out without any problems. What is going on?
If you're running 2009R2, make sure "Optimize for slow connections" is turned off under Tools, Personal Options, File. That should prevent your client from requesting deltas.
http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.borland.stserver.doc%2Fhtml%2Fhives.htm
As to the root cause of the delta retrieve error, that is probably a MicroFocus support issue. On older versions of StarTeam where deltas were kept (pre-2005), upgrades to certain server versions/patches could raise a similar error. Fixes ranged from cleaning out the cache directory on the server to running custom scripts from Borland to fix broken DB references.
Often when I do a checkout of a different branch, or a reset, I will get 'permission denied' errors from windows for one to a dozen files - but the particular files vary from run to run. Here's the output from a test I just did, with GIT_TRACE=1. The trace only added the one line before the error message:
$ git checkout master
trace: built-in: git 'checkout' 'master'
error: git checkout-index: unable to create file dotnet/src/myfile.cs (Permission denied)
D dotnet/src/myfile.cs
Switched to branch "master"
I'm pretty sure this is some race with a virus scanner or other indexing service on my machine. If the race persisted, I could use sysinternals to see what process has the file handle open. However, it happens very quickly, and I'm not aware of a tool that will show me this conflict. Surprisingly, I haven't found anyone describing similar behavior.
How do I make these errors stop, or diagnose the problem further?
I'm specifically looking to end the file access race by identifying whatever process is doing the simultaneous access. So suggestions for a tool that shows which process has a file locked when an edit is denied would be very helpful. I'm aware of 'unlocker' and similar tools which will show me what process holds a file locked for a period of time. This doesn't work for this issue, because the process keeps the file locked for a very short period. So the tool needs to collect the appropriate data without my intervention, as I'm too slow.
It might be the Windows Search Indexer, which tries do index files as they are created. I ran into this issue with svn checkout and had to exclude that directory from indexing before I could successfully checkout a full project.
See my post https://connect.microsoft.com/VisualStudio/feedback/details/676699/cannot-open-linker-output-for-writing-or-cannot-close-file
Not git related!
Sysinternals' process monitor reveals that Windows explorer interferes with newly created files, perhaps due to some plugin or what, but it happens.
Disabling UAC Virtualization seems to have fixed the problem.
See http://code.google.com/p/msysgit/issues/detail?id=320
You can begin with a:
GIT_TRACE=1
But it may not display much more than your original message regarding this file.
The usual cause is some opened editor which wants to reload the files when changed, and that can conflict with git's file manipulations.
That means: the usual strategy is to repeat your git command after having close as many other applications as you can.
I haven't found anyone describing similar behavior
See this thread for instance, ot this one, both on Cygwin.
What version of Git are you using (Git on Cygwin, or MSysGit, in a Cygwin session or a Dos session?)
You could try Filemon from sys internals