git (git-bash) on windows locks number of folders even when done - windows

I usually use git-bash to manage source code from my windows desktop. When I am done, I close the git-bash window or run the exit command.
Then, I noticed that a good number of folders used for git projects are locked by git. The only way to release the lock is to kill the git process.
Is there a way close git and all its processes when done using git?
Now, I am using PowerShell to track locked files and kill the related processes:
PS> openfiles /query | find "folder-name"
PS> taskkill /im git.exe
Note: I noticed the file lock using Windows Process Explorer File Handle Search utility. I had to run the utility with Admin privileges for this feature to find the locks. See the snapshot below.
I appreciate your help.
Tarek

Installing a new version of Git for Windows and disabling the file system watcher should fix the directory locking (this affects the core.useBuiltinFSMonitor setting):

Related

why the git bash in windows shows could not fork child process? [duplicate]

I have had up to 8 git bash terminals running at the same time before.
Currently I have only 2 up.
I have not seen this error before and I am not understanding what is causing it.
Any help would be appreciated!
Picture attached:
Found a similar issue and solution in google groups
I opened a windows command prompt and ran the command
$ tasklist
It looks as though the ssh connections I had made in my git bash shells weren't being closed when those windows were closed and were hanging the available git bash shell windows.
This may be a dangerous solution but from the windows command prompt I ran
$ taskkill /F /IM ssh.exe
Everything appears to be working again after this. It may not have directly been an issue of orphan processes, but this worked for at least for me.
Additional note: you can also kill other processes, for example like:
$ taskkill /F /IM vim.exe
In my case, it was related with the use of VS code. Previously I have opened VS code using a git bash terminal and executing
code .
then closing the terminal.
The problem is solved by closing all the VS code windows opened.
When you have any editor or IDE configure to open a terminal as git bash, then when the IDE/IDE is running, the git bash will spin up bash from "C:\Windows\System32\bash.exe" and any other attempt to open bash from a separate window is likely to crash.
The best solution is to kill the IDE/Editor bash and open from a new window or continue from the IDE/Editor command.
I see the problem on windows in git bash when I kill my git bash console without using exit. I found killing ssh-agent.exe task from windows task manager to fix the problem.
I address this with a workaround:
Close the Git Bash window.
Open Task manager.
Find the 'Git for Windows' process.
Kill it.
Open Git Bash.
It should be ok now.
Open task manager and kill process with name bash, this worked for me.
This happens when you exit git bash without terminating existing process. Just try and kill those processes that you started from git bash.
I was running node process inside git bash, so I killed all node processes
Steps to kill
Open Task Manager
Goto Details Tab
Look for node.exe(you look for you processes)
Kill it each and every node process
Open Git Bash again
To make life easier (this problems happens quite often) create a file called fixbash.bat in home directory and paste this:
taskkill /F /IM ssh-agent.exe
When problem occurs just open cmd and type fixbash.bat to fix a problem.
Or
Just paste the taskkill command into your cmd if you don't want to create a script.
Restart your machine.
(The other answers did not work for me. (I didn't try reinstalling. Restarting is probably faster.))
finally figured out what was causing this.
if we use code like this (explicitly or implicitly) i.e. in .bashrc file
eval $(ssh-agent -s)
ssh-add ~/.ssh/id_rsa
it spawns a new process.
if you don't exit it and just close the window, that process is still running. so each new bash opened just keeps adding new ones w/out disposing old ones.
when done with a bash window, simply hit ctrl+d or type exit to kill the agent process, and you should not run out of forks.
In my Case I need to kill Git bash in Windows.
So opened Command Prompt and ran below command
$ tasklist
It will list down all running tasks, then need to kill bash.exe task using below command
$ taskkill /F /IM bash.exe
For me (or anyone running protractor, which may spin up a standalone Selenium/WebDriver server), I needed to taskkill the specific webdriver which was running my tests.
So just a different argument:
or your chromedriver version may vary
taskkill /f /im chromedriver_2.34.exe
Note your driver may vary:
IEDriverServer*.*.*.exe vs chromedriver_*.**exe
Your driver may version may vary:chromedriver_2.34.exe vs chromedriver_2.33.exe
This problem got worse after protractor quit without closing the automated /test-driven browser, (due to a separate issue I don't yet understand.) Naturally many chromedriver tasks remain running, that's why kill them.
Seems to be an issue with the processes launched from the git bash indeed, like #mamacdon suggested in his comment on the top answer by #Scott Newson.
For me, the issue appeared if I launched a vscode from the bash with code, and if this instance of vscode launched an integrated git terminal while the original bash was still running.
Doesn't matter whether that terminal was launched at the start or later, as long as it was while the original bash was still running.
Didn't happen when the bash was closed before the integrated terminal was opened. Didn't differentiate between exit and closing bash via windows. Didn't happen with another older bash window still running.
The way to deal with it was for me to close the terminals in vscode with exit or 'Kill Terminal' (be careful not to mix that up with 'close pane'), or of course, closing vscode itself.
If you get this error try to remember what you launched from the bash and kill it. If the other answers worked for you, it's probably just that these are the things launched by your bash or launched by processes you launched from the bash and they somehow were getting a child of your original bash.
If you are using Visual Studio Code and you can't find ssh-agent.exe or can't taskkill it and after opening Git Bash you get that error, just go to your VSCode open Terminal>New Terminal and just press the trashbin icon the (Kill Terminal). e.g (1:bash) if you got multiple then just kill them all and you should be good.
I tried to kill all my git terminals in task manager solves the problem.
This works for me too.
good luck.
Open your Task manager, search "sh" procces and kill them.
Good luck
In my case, I was running jupyter-notebook from Git Bash and closed the terminal without closing the notebook. When I closed all running git bash terminals and tried to open new terminal, this gave me the error:
Error: Could not fork child process: There are no available terminals (-1).
Solution
taskkill /F /IM jupyter-notebook.exe
After that, I was able to run commands in git bash terminal.
i found that killing msys2 terminal in task manager solves the problem
On a more recent version of git for windows, the process to kill in task manager was "GitExtensions.exe". Killed that and the terminals restarted with no issues.
Please find the ssh-agent process in the Task Manager window.
After you stop or kill the ssh-agent process the error will disappear.
Open Task manager, find bash.exe process and kill it. Helped in my case.
In my case I had visual studio code running and closing it resolved the issue.
Windows 10 this worked for me:
1) open cmd as administrator
2) type:
taskkill /f /im git-bash.exe
3) If there was an Error: The process "ssh-agent.exe" not found. then:
type:
tasklist
4) Find and kill every process with words like "bash" or "git" (This may be a dangerous solution, but once you will find the process name, next time you will know.)
taskkill /f /im ***.exe
Im my case, the solution was to close Visual Studio Code -where I had console running too without noticing-
After closing it all back to normal.
Hope this helps someone.
In my case, I needed to kill sh.exe
taskkill /F /IM sh.exe
Many answers here are suggesting different processes they need to kill in order to be able to open a new Git Bash terminal. In my case there were multiple conhost.exe processes running which I had to kill before I could open another window successfully.
Perhaps more importantly, is why it happened. I think I know exactly what I did which led to this state. I noticed that when typing git log, if I then resize my Git Bash window, it would hang. (Pressing q would not exit the log and I could no longer type commands.) I ended up closing the window and opening another one. I was doing some testing of this repeatedly to see if I could figure out a solution to the freezing after resizing, and after doing this multiple times (probably around 10 times), I received the error in this question. The results of my testing are:
Opening a new Git Bash Window starts the following processes:
conhost.exe
git-bash.exe
git.exe
mintty.exe
Now, when you type git log, 4 additional processes open:
bash.exe
conhost.exe
git.exe
less.exe (this will only stay open if your log cannot fit on one screen)
When you close Git Bash, those 8 processes all normally go away. However, due to a bug, (which I think is possibly in less.exe) when you resize the window while viewing the log, Git Bash hangs. If you now close the window only 6 of the 8 processes close. Both less.exe and conhost.exe stay active. In my case, eventually enough conhost.exe processes built up and caused whatever the issue is that leads Git Bash displaying the error and not starting.
That said, I tried to repeat the issue but gave up after 20+ tries, which was more conhost processes than I had to kill when I was in the problem state. I suspect it's not a process number but something about the state of one or more processes that leads to the error. Obviously since other answers mention closing different processes, the "thing" that isn't closing properly and fighting against Git Bash can vary, depending on what tools you're using.
Note, I'm using Git version: 2.37.1.windows.1.
For windows, in task-manager kill sh.exe.
In my case the problem was the file [git_install_dir]/etc/nsswitch.conf
I previously followed the instructions given here:
https://cygwin.com/faq.html#faq.using.startup-slow.
But this caused the "Could not fork" error instead.
My wrong nsswitch.conf file was:
passwd: files
group: files
So I restored the file and problem solved. Now my [git_install_dir]/etc/nsswitch.conf is:
passwd: files db
group: files # db
db_enum: cache builtin
db_home: env windows cygwin desc
db_shell: env windows # cygwin desc
db_gecos: env # cygwin desc
Tried the following solution which worked for me:
Kill all existing git.exe
Added my credentials for BitBucket in the Windows Credential manager under the generic credentials section.
Reinstalled git, it is now working fine.
In system bash type:
ps
Kill any bad looking process:
kill -9 <ID>
Worked for me.

How to execute batch file as Tortoise SVN hook

I wish to run a batch file either in START commit or PRE commit via TortoiseSVN hook scripts. No tests I have done has worked.
I have created a batch file (svnadd.bat) that just writes a message to a text file for now, so I know it fired. However, the batch file does not appear to run as the message does not get written.
echo YES>C:\Temp\commit.txt
Here is my hook setup.
My process. Right click on a folder which is under svn version control and select SVN Commit. The commit dialog shows, however, the batch file does not execute.
All svn software, repositories and folder/file structure under svn control reside on the same computer/drive.
As per the screen shot, I also tried adding cmd.exe to the front of the command line as
C:\windows\system32\cmd.exe /c C:\Tools\SVN\svnadd.bat
I config it like this. It is successful.
post_commit_hook.bat:
echo Hello World >file.txt
After commit, file.txt will be save to
E:\SVN\XXX\branches\autoCommit
#lazybadger's comment provides the answer in that the "path" needs to be at the highest working copy path. For me, this is C:\Projects.
Once I set C:\Projects as the path, the script hook ran.
You can try and use team city, if you want certain scripts to be executed on SVN events (like SVN Commit). Though TeamCity is mainly used as a build server, I think it can do what you desire.

How to make all the commands which come with git available globally from the windows command line?

Not long ago I found out a precious thing which comes with the git install:
http://git-scm.com/download/win
From git's bin folder on the command line you have almost a linux console available. Commands like curl, touch, kill, ssh, grep and lots of others. The problem is that when you move out of the bin folder, of course they become unavailable. Is it possible somehow to make these commands available globally from the windows command line?
Use this one Git Shell from Github
Has some cool git features in it, much better than default windows command prompt.
Few good points are:
Tab completion
Prompt for current branch
Colors highlighting
You simply add the full path to you "bin" folder (e.g. c:\git\bin\) into Windows "PATH" environmental variable.
As opposed to repeating how to do that here, plenty of help on the web.
http://www.computerhope.com/issues/ch000549.htm
Note: you may need to close and re-open the command window you are in if you add through the control panel.

windows batch file exits when running mercurial commands

For daily backup of my mercurial repositories on Windows XP I used a simple batch file hg_backup.bat which just did some directory changes and mercurial calls with a pause command in the end like this:
#Z:
#cd \hg_backup\drawings
hg pull -v
#cd \hg_backup\src\scripts
hg pull -v
#cd \hg_backup\eagle4\lbr
hg pull -v
#pause
This worked fine with mercurial up to 1.7 (installed with TortoiseHg). However since mercurial 1.8 it starts the very first mercurial command and then exits abruptly without reaching the following commands or even the end of the script. The command window just disappears.
I had the same problem some time before, when I tried the same thing with git, but didn't investigate further, because I use git for one repository only. It seems to me, there's some return code of the hg command line call involved which causes the script to end instead of executing the other command but I couldn't verify this yet.
Has anyone an idea why this happens or maybe even how to fix it?
If your hg is a hg.bat or hg.cmd, use call hg and see if it starts working.
The command.com shell executes batch files replacing the old script (to save memory), and requires using call to start a batch script and continue execution later. This behavior remains in Windows cmd.exe for compatibility.
I had the exact same problem, but the solution provided by #grawity didn't work for me (and I have no idea why).
The solution in my case was to replace call with cmd /C, like so:
cmd /C hg sum
cmd /C hg stat

Access denied to file on windows 7 for Administrator account

I want to delete my git repository (.git folder) created by git on my windows 7 box. It says access denied to .git/refs/header folder.
I open a console with Administrator role, issue command "takeown /F heads /A /R", it still says "ERROR: Access is denied.", neither can i do via GUI security dialog.
Any suggestion?
Regards,
Green
An access denied error may mean the file is in use by another process and, for a GIT repository, that seems more likely than a file permissions issue.
(I'm assuming GIT is like SVN where every file in the repository is created by your own account with standard permissions. If that's not the case then I may be wrong.)
As a first step, run Process Explorer as Administrator and push Ctrl-F to open a window where you can type the filename and see which processes (if any) have that file open.
When I say "run as Administrator":
I don't just mean when logged in as Administrator. Windows 7's UAC means Administrator accounts don't run things with full admin access by default. Right-click procmon.exe and choose the "Run as Administrator" option.
I assume you're already familiar with this from running the command prompt as admin. If you just changed to an admin account, but didn't use "Run as Administrator" on the command prompt, then that could be why the takeown command failed. The command prompt should say "Administrator:" in its window title if it is properly elevated, unless UAC is off entirely.
If one or more processes are listed, confirm the full file path in the list (in case some other file on disk has a similar name).
Close any processes which have the file open. Try to close them normally if you can. As a last resort you can end-task them. If it's a process running as another user/account, it might be a service which you can stop.
(Ensure View->Show Processes for All Users is ticked, then find the process in question via the PID column. If you think it's a service, hover the mouse over it and a tooltip will appear telling you the name(s) of any services it is running.)
If you cannot find any process accessing the file, or closing them all still results in an access denied error, and you are definitely trying the deletion from an elevated command prompt, then you might want to try telling Windows to delete the file the next time it is rebooted. You can use the SysInternals MoveFile tool for that.

Resources