I successfully installed SourceTree on a Windows 7 PC today.
After the installation I successfully used SourceTree, closing it when I was done. But now I can't restart SourceTree. It is not listed in Start/All Programs. There is no startup icon/link anywhere. I can see it in Control/Panel "Programs and Features."
This is no trace of SourceTree in Program Files.
There are lots of SourceTree files in AppData/Local/SourceTree, including at least two SourceTree.exe files, but they seem to be installation programs.
I know SourceTree is present. But where is the main executable? How can I start it?
The Folder you are looking for is in the following directory:
(C:\Users\YourUserName) \AppData\Local\SourceTree\SourceTree.exe
If the above folder is not created then should be a bug, reinstall with the latest version (>=3.1.3, https://www.sourcetreeapp.com/).
The .exe file is not contained in the folder \AppData\Local\Atlassian\SourceTree
Related
I have vsc version 1.63.2. I'm getting the following notification:
"File changes watcher stopped unexpectedly. A reload of the window may enable the watcher again unless the workspace cannot be watched for file changes."
When I click the reload button, the issue is temporarily fixed and Source Control shows changes to my files. Git in CLI is working fine; git log --raw shows changes to my files correctly. I've tested brand new and old repositories and workspaces. The problem occurs in all of them. Any help troubleshooting this is greatly appreciated!
I just ran into this issue today and found my solution by viewing the "Window" logs using the "Developer: Open Log File..." command from the Command Palette.
In my case, the problem was that I had added a folder to my workspace that I had since deleted on the file system. The log in question looked something like:
... [error] [File Watcher (parcel)] Unexpected error: Invalid handle (EUNKNOWN) (path: \path\that\no\longer\exists)
... [error] [File Watcher (parcel)] restarting watcher after error: Invalid handle
Hopefully viewing this log helps you find out what's breaking in your specific case.
I also encountered this problem. I was using VSCode and opening a folder in it on WSL Ubuntu 20.04. The solution for me was to install the VS Code Remote - WSL extension.
I hope this will be useful for someone.
TLDR : on Windows 10, if you have Cygwin64 installed and you got a Git For Windows update, check Git for Windows path comes before Git from Cygwin path in environment variables.
Long version : Just got into the same error today. The Git Lens extension was not working anymore.
I'm on Win 10, so there is no way (at least I didn't find one) to increase the limit of watchers like on linux. My VS Code is v1.66.2, Git Lens extension is v12.0.6.
In my case, the logs said :
... [error] [File Watcher (parcel)] Unexpected error: Invalid handle (EUNKNOWN) (path: cygwin\g\path\that\exists)
Notice that ENOSPC !== EUNKNOWN
So I searched everywhere with little to no success, except here where Gordon Christopher Weeks's answer actually hinted me towards that logs.
Then I remembered several things :
I have a terminal installed that's called cygwin64 and that allows me to use some linux utilities otherwise not available on Win (like rsync);
two days ago, I authorized an update for Git for Windows (2.35.2);
when I installed cygwin, the tutorial I followed told me about following a certain sequence in the Windows path environment variable
So I checked the path variable, noticed the Git update deleted the initial path to git and put it in the last place. I only had to move it up, before the cygwin64 path to git.exe (a git utility is included with cygwin) and everything's back to normal.
Hope this helps and so you won't waste the time I did !
[Possible quick solution] First thing to check is to see if you are tracking a WSL folder in a Visual Studio Code Explorer workspace AND you switched VS Code back to windows (was in a WSL distro).
If so, then right-clicking on it and selecting "remove from workspace" will also remove it from the file change watcher.
Refresh the file change watcher (bell icon, lower right corner of window) to see if it cleans up the problem.
This was the issue I had with the system.
A few days ago I installed Kali Linux. I'm trying to use Code-OSS instead of VSCode, since newest version of Kali doesn't have the libraries needed to install the normal one.
If I try to open a folder in Code-OSS from terminal using code-oss . or code ., it just opens Code on a new 'untitled-1' document, or opens the folder I was before closing Code-OSS. It doesn't open the folder I was in the terminal.
In these cases I need to open the folder I want through File > Open folder > search for folder and then open it.
The same just occurred with git commit or git commit --amend; it opens a new document, not the one I want to open.
I spent sometime searching for a solution on documentation, stackoverflow, google but could not find anything.
I cannot find any way to resolve this problem on Code-oss. Apparently it happened just with me.
Surprisingly for me, I was able to install VSCode following this tutorial, and it apparently managed to ignore the lack of libraries of Kali Linux that I mentioned above.
I hope this solution prevent any person in the future to get stuck on this.
I had the same issue when I first installed Kali-linux on my VM. Pretty anoying.
Just intall vscode by running :
sudo apt update
sudo apt install code
It will unistall code-oss and install VsCode, and it works now.
I have Visual Studio Code installed in Ubuntu 20.04. I love how it works. I installed it from the tar ball. Same with the SDK. I just found that those appear to work better than installing from deb packages.
I created a desktop file so I could add Visual Studio Code to the dock and launch it that way, but what I've noticed is that projects won't compile. I get errors stating it can't find the project even though the errors are listing the folder where the items exist.
The only way I can get it to work is to:
Open a terminal.
Navigate to the folder where the project files reside.
Launch code from the command line.
Then it works. Otherwise, I get a pop-up error that says "The preLaunchTask 'build' terminated with exit code -2" and then the terminal window is filled with errors.
Here's the last of the error messages and then I opened up a terminal and it shows that I'm in the folder for the project and the csproj exists there:
This also happens if I install Visual Studio code from a repository. It seems launching it from the Unity desktop breaks something. But if I launch it from the command line in a terminal session from the folder where the project resides, then the problem goes away.
I can also reproduce this error from the command line if I launch Visual Studio Code from a different folder than the project I'm trying to compile.
Is this common? Just curious. I'm wondering if because when I launch it from the Unity desktop, it's launching under a different
I got it working under 20.04. I must have done something wrong so I did a wipe of the .NET Core install and reinstalled it all using the bash shell script and then was able to install Code via Software Installer tool. Not sure why it didn't work before, but it works now.
I've been using Bash for Windows recently (its the Ubuntu "app") and I can open VSCode from the bash command line but when I try to save any modifications I've made to the file, it just says permission denied.
I've tried creating the files directly from VS Code's terminal but in that case it doesn't print out an error message but it also doesn't save anything.
That happens because you dont have permissions to write in the system32 folder. If you run the Ubuntu application as an administrator, you'll get the permissions to write. However, you won't be really in that file, because of the way that the virtualization of files and errors might happear doing so, and I do not recommend to run the console in a privilege mode (for seccurity issues).
Fortunately, in version 1903 of Windows 10, this will change, and you'll be able to navigate the WSL folders via Windows Explorer, and for sure that issue will disappear.
Edit: the best practice, you do the work in a folder in the Windows File System, and cd to there in the WSL console. VSCode has this integrated very well, if you have an open file in VSCode you can just do New Terminal and choose a WSL terminal. The terminal will already be in the folder where you file is.
I'm running Eclipse under a Windows 7, 64-bit installation on which I have administrator privileges.
Since I first installed Eclipse many months ago, I've been able to keep it up to date with the Help > Check for Updates function—but starting a couple of weeks ago, it gave the message
Insufficient access privileges to apply this update.
Even when I ran Eclipse as an administrator, I continued to get this message. How can I fix it?
For anyone using Linux: I had this problem in Ubuntu because I had installed Eclipse in /opt, which was owned by root.
To get the updates, simply run Eclipse as root and then select the Help -> Check for Updates again. In general running applications as root is not a good idea, but if it's just to do an update... well that's what the root account is for :)
cd /opt/eclipse
sudo ./eclipse
Another (simpler?) approach which worked for me is to simply give the group "Users" write permission on C:\Program Files (x86)\eclipse.
Now, this is a security consideration, but you're NOT granting access to the whole of C:\Program Files (x86), just the eclipse installation.
I found a workaround for this stupid bug in Eclipse. Selecting updates one-by-one is disabled, but if you click Select all and then deselect the ones you do not need, you can proceed.
In Windows another option is to set the "Run as administrator" property on the Eclipse shortcut that you're using to start Eclipse. Right click on the shortcut and choose "Properties" from the dropdown menu. Click on the "Shortcut" tab in the Properties dialog and then click on the "Advanced..." button. In the Advanced Properties dialog set the "Run as administrator" option.
Hit same problem on Macos sierra 10.12.3 after clean install of Eclipse JEE Neon R. A clue was that my mac showed a dialog when I launched the app that asked:
“Eclipse.app” is an application downloaded from the Internet. Are you sure you want to open it?
When the updater dialog box showed "Insufficient access privileges to apply this update" I checked the Eclipse.app directory (I had downloaded & unpacked the .tar.gz file, if that matters) and saw this:
drwxrwxr-x# 3 chris staff 102 Jun 13 2016 Eclipse.app
I examined the extended attribute and saw this:
$ xattr Eclipse.app
com.apple.quarantine
That quarantine attribute seems to block the Eclipse updater! I removed that extended attribute like this:
xattr -d -r Eclipse.app
After that Eclipse updated itself very happily. HTH
For Linux Distros, most personal apps for all users are installed in the /opt/ folder. This folder is owned by root. My solution which has been tested to work is simply to open the opt folder in terminal call 'ls' to make sure you see the 'eclipse' folder in your current directory. It may be inside another folder.
Then simply use this command replacing 'user' with your username.
sudo chown -R user:user eclipse/
and that's it. Of course only you will be able to run updates on eclipse but I imagine you are the primary user of the computer.
Solving the problem was a multi-step process for me:
In a thread on another forum I found the advice that Eclipse should not be installed in C:\Program Files (x86). I had indeed installed (unzipped) it into that folder, so I moved it as advised to C:\Users\....
When I loaded Eclipse in its new location, I got a different message when I attempted to scan for updates: "There are no update sites to search".
I temporarily re-established my installation in C:\Program Files (x86), loaded it, and used Window > Preferences > Install/Update > Available Software Sites > [select all] > Export... to create an .xml file with my software sites.
Back in the C:\Users\... installation, I used the the same menu command (except Import instead of Export) to pull in the contents of that .xml file.
Now Help > Check for Updates is again functioning as it used to.
I fixed this problem (windows) by re-opening eclipse by right-clicking the eclipse.exe and selecting "Run as administrator".
Not sure why this step was needed all of the sudden but it worked. After my upgrade (I upgraded from eclipse sdk 4.3 -> 4.4) it still lets me make updates without running as administrator.
From Powershell, I set permissions on the folder like so:
& icacls "C:\ProgramData\chocolatey\lib\eclipse-java-neon\eclipse" "/grant" "domain\user:(OI)(CI)F" "/T"
Note: I had a different install location, as I used chocolatey to install eclipse