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)
Related
When i try to start one application (for instance application A.exe) error was throwing from already installed msi file (for Ex: B.msi) as "The feature you are trying to use is on a network resource that is unavailable or enter an alternate path to a folder containing the installation package 'B.msi'"
I have read some articles related to this error but all of them explaining if installer have any issues (if file have been damaged, deleted, moved, or quarantined by an anti-virus application) this error will occur but here when I try to launch one application then it is showing above mentioned error with another package name (B.msi) which I already installed.
Please let me know the cause of this issue it would be helpful to trace out this issue.
Note: For older version of our application don't have this issue (For creating installer earlier we have used Wise tool now using WIX tool. Is there any issue with WIX installer?).
Self-Repair Problems: This is generally a self-repair issue. I have written more times about this than I care to count, I'll see if I can send you here: MSI self-repair - the scourge of society.
Explanation: What is actually happening is that your installation goes through an integrity check when launced via an advertised shortcut, and a resource is found to be missing. The MSI will then try to repair itself (self-repair), but it is unable to find the required source files to retrieve the file it needs to reinstall - since the source files are no longer available at the location where you installed from. It is a good idea to install from a permanently available network location using administrative installations - especially for corporations.
Missing Source Files Resolution: In your case - to sort out the missing source files - you can either uninstall and reinstall (uninstall should not need source access in normal cases), and then preserve the installation files at a permanently available location (solving the problem for the future), or you can browse to the installation source when you are prompted to do so for your current installation (and there are some ways to automate setting new source paths). The installation source must be the one used to install the software originally (unless you know how to hack it, which is very involved).
Self-Repair Resolution: To sort out the actual self-repair conflict, you essentially need to find the culprit component causing the repair in the event viewer and then find some way to resolve the situation. All linked or explained in the above answer (repeated here). Proposed "real-world solutions" can be found in section 5 here: What do I do when launching an application triggers repeating, endless Windows Installer self-repair? As a workaround, you might want to try to launch the EXE files in question directly, to verify that the self-repair does not happen (generally this will prevent the self-repair, but it can still happen if there is a COM conflict or some other advanced conflict).
You can see a list of "Primary Cause of Self-Repair" some way down in this answer: How can I determine what causes repeated Windows Installer self-repair? (bad MSI packages with conflicting resources - COM conflicts?, security software quarantining files unexpectedly, cleanup scripts wrecking havoc, etc...). I would recommend you skim this list for ideas.
Uninstall Problems: This "installation source not found" problem can also occur so it prevents uninstall in special cases. Here is an answer which tries to summarize aspects of this problem: Powershell Silent Uninstall "Microsoft Report Viewer Runtime 2012" (somewhat too elaborate, but worth skimming I think).
Some Links (for reference and easy retrieval):
Installshield 2013 Installscript MSI: Wrong .msi location during Repair
Wix / MSI : Unable to uninstall
Uninstall without an MSI file
I would like to use Git for a software project which resides inside an encfs enctrypted drive mounted via Dokan (Windows environment). The Encryption of the files works just fine, unfortunately Git does not seem to like working in this environment. When initializing the Git repository I encounter the error message:
error: could not commit config file w:/djangodance/.git/config
When committing I encounter this - disk is writeable and quota is not exceeded:
fatal: Repository has been updated, but unable to write new_index file. Check that disk is not full or quota is not exceeded...
So far I have learned that Git does not seem to like certain drive-mounting-setups. This article (mounting remote filesystem via sshfs) proposes a workaround option (-oworkaround=rename).
My questions:
Did I locate the source of the problem correctly?
Is there some similar setup for Dokan which works with Git?
Is there a different approach which could satisfy on-the-fly encryption using Windows? I'd rather not use TrueCrypt since it is not as useful in combination with Dropbox.
Thank you for any hint!
Dokany is a fork of Dokan. It is very active by the maintainers and the community. It is now know as the main solution for writing driver and porting FUSE to Windows with the same code.
It also have the fix that you would be interested:
https://github.com/dokan-dev/dokany/pull/39
There was a problem with MoveFileEx. Without the fix this API fails with "permission denied" because the target file is opened and cannot be deleted.
Now the git command works via dokan!
The latest release of Dokan appears to be nearly three years ago. I don't imagine you'll get much support with it, even from the community.
You may want to consider using Bitlocker, a full-drive encryption system. Or possibly Encrypting Filesystem to encrypt your development directory. Both of these options are included in recent versions of Windows, and should be fully supported by Microsoft.
I created a MSI package with visual studio. It works fine for 80% of the users (some have errors with privileges and the like), but for two users the installation fails with the error message:
The feature you are trying to use is on a network resource that is unavailable
Which I find very odd because all the MSI does is set some registry values and put an OCX control into the system. Nothing with any network devices or anything else.
It also refers to a install[1].msi (when the actual MSI is called install.msi) which it supposedly can't find, which is obvious, because such a file never existed and is neither required for the installation nor even referenced in it in any way.
The package tries to locate this non-existent other package under C:\Documents and Settings\XYZ\Local Settings\Temporary Internet Files\Content.IE5\M84S9GA4\, even though I started the MSI out of the local drive D:.
How can I resolve this / get closer the underlying cause?
A verbose log file should show you the exact error causing the issue. If it doesn't happen consistently, you'll probably be best served turning on the logging policy to get a log file all the time and when it repros, grab the log file really quick.
Alternatively, if you have a repro situation you can get a log file immediately by doing:
msiexec /i path\to\your.msi /l*v install.txt
As for the root cause, the fact that that the name is install[1].msi makes it sound like the MSI was downloaded using a web browser and launched out of the browser cache. The Windows Installer is very particular about the name of the MSI, you can read about that in an old blog entry of mine. The end result is that shipping a 'naked' MSI on the internet is never a good idea. Maybe you're seeing these errors when shipping a newer MSI? If so, that would make a lot of sense.
A verbose log file will show you for sure.
I've checked out a module from CVS onto a newly installed Windows 7 machine. The virus scanner has not yet been installed.
Later, when I try to do an update, I get the following error message:
cannot rename file CVS/Entries.Extra.Backup to CVS/Entries.Extra: Bad address
Has anyone seen and resolved this issue before?
I had the same issue, had to exclude the library which I checked out to from the anti-virus monitoring.
Try to disable your anti-virus and checkout the code again.
It could be issue with VirtualStore - make sure you didn't checkout to Program Files or other protected areas.
And if you can - convert your repository with cvs2svn - you'll save yourself a lot of time.
I had the same problem. After disabling antivirus/malware protection tool, I was able to resolve the problem. Also, ensure that cvsnt.exe should be running in an elevated mode.
I've got an MSI based install that I've wrapped in an EXE file as per my installation packaging software (which is Wise Package Studio 7.0 SP2).
I've made many changes to the install, and every time I've tested them, they've worked just fine... up until now.
I changed some text on a dialog box for when the installation finishes and now it seems that no matter how/where I run the installation from, it won't take my "new" version. It continues to "think" it's already installed and even shows an older iteration of my dialog text at then end of the removal/repair/modify.
It's almost like it's cached that MSI/EXE somewhere and instead of running the one I've recompiled (and fixed the message/made changes) it continues to run the "old" one from somewhere.
Any idea what to check for/what could be going on here? Is there windows folder I need to go check? I'm on XP SP2.
Try running on a different machine, this will definitely rule out any local caching.
Check that the changes you have made are actually in the MSI. (use Orca to do this.)
Okay, so I tried this using an XP VM and taking a snapshot before installing. Looks like somehow the previous install was corrupt and was somehow caching itself on the original test computer I was working with.
By going to a clean and fresh PC, my changes were there and the script worked as expected. Now, I don't know what happened to cause the installation to cache like that somewhere on the PC, but at least I found a resolution.
I'll update this question with the location of the cached files if I can track them down...
To remove any cached Windows Installer information, you can use MSIZAP. My guess is that you haven't changed the package code so windows sees it as the same version of the installer (I'm not sure about WISE, but InstallShield is usually configured to automatically change the package code each time you rebuild.)
As far as the location of the cached files, this is configurable so have a hunt around in WISE and you should find it.