It is currently in use by another Gradle instance - gradle

I want to do some basic functions. I'm running/building it in command line. I am referring User guide. And, doing some simple tasks.
When I start to run simple tasks, it was build successfully. But, After some times, it is showing "It is currently in use by another Gradle instance" and becomes BUILD FAILED. I'm using a terminal for run the task. I didn't run anything at that time.
If I closed the terminal which generate the error, this problem would be solved. But, I know that it is not the solution for that.
Why is this error coming frequently?
How to solve it?
And, Please refer any link to improve my knowledge on Gradle Build system in Android.

Remove the lock files in the gradle cache by executing something like this:
find ~/.gradle -type f -name "*.lock" -delete

Sometimes fast way comes in a non-elegant deal, there we go:
Find first the # of all gradle process running on
ps -A | grep gradle
After that, get the IDs, Kill 'em all one by one
sudo kill -9 <process ID>
Now you're good ;-)

I was stuck with this error and had to blow away the contents of my user's .gradle/caches/ folder and the contents of my project's .gradle/ folder to get going again.
Not sure what caused it, possibly a failed build that kept these files in a locked state?

gradlew --stop
I had a similar error, running the above command worked for me.

For Windows machine:
Open Task Manager(Ctrl-Alt-Delete and check Process)
-> If you run two instance of android studio, Close One (End Task)
-> Then close OpenJDK Platform Binary
-> Gradle sync now on AndroidStudio and it will work now

Just kill java.exe process fix my problem.
-- Edit --
if not fixed then:
kill OpenJdkPlatform proccess.
if not fixed then:
remove all ".lock" file from .gradle directory and sub directories (windows: C:\Users\Username\.gradle).
if not fixed then:
rename or delete .gradle directory and try again.

That Gradle failure message is usually followed by the relevant process IDs, so it would be
Gradle sync failed: Timeout waiting to lock daemon addresses registry [...].
It is currently in use by another Gradle instance.
Owner PID: 1234
Our PID: 5678
Owner Operation: ...
In order to unlock, just kill the owner process:
sudo kill -9 1234

For MAC machines
Please open the "Activity Monitor" and select the "memory" option and force quiet the Android studio and other running java processes, it will solve this issue.

sometimes you need to run this code a few times after each build error
for me it takes two times first i get lock error I run this code then again i get the lock error for another file so I run the code again and at the end it works properly.
find ~/.gradle -type f -name "*.lock" -delete

This may be happening because there is more than just once instance of Android Studio.

I was facing the same issue in my project but I resolved this by invalidating the project, so follow these steps in the android studio
File -> Invalidate Caches / Restart...
Android studio will restart and your problem should be fixed.

I could be late but look like quick and efficient solution.
Execute following steps.
Execute ps -ef | grep gradle
Open terminal and move to ~/.gradle/caches path
Execute find ~/.gradle -type f -name "*.lock" | while read f; do rm $f; done
Delete .gradle and .idea folder from Android studio.
It's done.

Having the same issue on a Mac, none of the above worked for me. What worked , though, was opening the Activity Monitor and closing a running java process. I also noticed that an .hprof file was generated, which I deleted. After that, I ran my project and it worked.

I had the same issue on mac:
take care, that your project is NOT on an external hard disk. The location of your project must be on the hard disk with your operating system.
(Building an Ionic app)

press CTRL + SHIFT + ESC to open task manager now find OpenJDK and kill it goto where the error is pointing to like
D:\.gradle\daemon\4.10.1\registry.bin.lock
delete the file and resynce and you're good to go.

For Windows OS:
I figured it had something to do with a lock file so i simply went to .gradle\buildOutputCleanup in the project folder and deleted the cache.properties.lock file and rebuilt the project. It was working perfectly.

Along with the top answers here, you need to figure out why the gradle processes exit without releasing the locks to fix it permanently.
In my case, I did all *.lock file deletions and Android Studio's Invalidate Cache option. But the problem kept coming back.
Running gradlew manually in the terminal showed me that gradle processes prematurely exit when the JVM heap space is exhausted. This answer helped to fix it.
./gradlew build #to detect what crashes gradle processes
./gradlew --stop #to stop any running gradle processes
After fixing the problem (eg: heap exhausted)
find .gradle/ -type f -name "*.lock" -delete #delete lock files
./gradlew build #Try building the project

On windows . In Android Studio open Terminal window (used to start in project's root folder) and tipe in
.\gradlew --stop
mine responded:
Welcome to Gradle 7.3.3!
Here are the highlights of this release:
- Easily declare new test suites in Java projects
- Support for Java 17
- Support for Scala 3
For more details see https://docs.gradle.org/7.3.3/release-notes.html
Stopping Daemon(s)
1 Daemon stopped
And now it plays ok with builds and runs as previously

I was too stuck with the same thing. But it was sorted soon. Just delete the file:
D:\.gradle\daemon\6.1.1\registry.bin.lock
also, I've ended OpenJDK from task manager. Idk it helped or not but both of them solved the problem.

Just delete yours .gradle folder inside android folder
If it is not available in your File Explorer(WINDOWS) or Finder(MAC)
For Windows :
go to view option and check show hidden files
For Mac
just press cmd + shift + .
Now run your app.

It was not necessary for me to remove any files to fix this error.
The issue I had is that Gradle instances had hung and were 6 command prompt entries in my task list that were spawned by Java.
Forcing the command prompt instances to close allowed me to continue work as usual.

Its Work for me for
Problem:-
"Error:Timeout waiting to lock jars It is currently in use by another Gradle instance. Owner PID: 6896 Our PID: 5048 Owner Operation: Our operation: Lock"
Solution:-
close the Android Studio and Open Task manager and end the process java.exe
open the derectory ....gradle\caches.
Delete the jar2.lock file.
Open android Studion and clean the project.

Have tried all this answers, including kill java process, delete .gradle in HOME_DIR and in project dir, restarted Android Studio, and even restarted OS.
It started to work normally only after I launched gradle sync.

Very simple solution:
no need to kill Android Studio , just Kill OpenJdkPlatform process,
then delete the .lock file located in:
rootProject/.gradle/<version>/taskHistory

While killing the process and/or removing the lock file works, Gradle should be able to handle this on its own, solving the problem permanently. This problem report hints at the solution: Gradle cannot communicate with the gradle service.
Have a look at your local network firewall. In my case,
allowing outbound traffic from 127.0.0.1 to 127.0.0.1,
sudo iptables -A OUTPUT -p udp -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
allowing incoming traffic from 127.0.0.1
sudo iptables -A INPUT -s 127.0.0.1 -p udp -j ACCEPT
solved the issue. A discussion of a similar problem at github.
And, Please refer any link to improve my knowledge on Gradle Build system in Android.
The udacity gradle course, if you have some time.

open terminal and move to project path then run depending on the operation system:
gradlew clean or ./gradlew clean

I had same problem and i did two steps and it became solved.
My JDK was not installed on Mac (i forgot to install) i installed it.
I deleted all items from caches folder located in this path /Users/icon_developer/.gradle/ and rebuilt the project.
It worked!

For Windows Users:
That Gradle failure message is usually followed by the relevant process IDs, so it would be
Gradle sync failed: Timeout waiting to lock daemon addresses registry [...].
It is currently in use by another Gradle instance.
Owner PID: 8080
Our PID: 89765
Owner Operation: ...
In order to unlock, just kill the owner process:
taskkill /PID 8080 /F
taskkill /PID 89765 /F

For Mac users on first Gradle sync
I had the same issue when cloning from GitLab using IntelliJ.
In fact, as mentioned here : https://stackoverflow.com/a/53269914/2231299
you need to specify an internal hard disk.
So here were the steps in my case:
• Clone locally
• Wait for 1st gradle syncing to perform
• move directory to external hard disk
• reopen project at new location, and then gradle should work fine, even on external hard disk.
Comments:
Don't be afraid to re-commit if it looks like the files have some changes. It might just be indentation or line breaks issues, since your external disk might have a different format than your original mac disk.

In my case the culprit was restrictive firewall, part of the antivirus system.
According to the https://discuss.gradle.org/t/timeout-waiting-to-lock-file-hash-cache/21961/2 and https://github.com/elastic/elasticsearch/issues/50954#issuecomment-576772154, gradle-issue-8750, gradle server is keeping the lock and releases it on request of other gradle process. The communication goes over UDP socket on localhost. Thus if there is a firewall blocking this communication, gradle keeps file locks and other gradle processes cannot continue.
Try disabling AV / firewall to see if problem vanishes. Then run gradle as following to get better insight what is going on.
gradle --debug --no-daemon
The debug log shows owner of the lock, if the problem persists, kill the owner of the lock.
2021-05-20T19:32:41.105+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] The file lock is held by a different Gradle process (pid: 67494, lockId: 628651820260732672). Pinged owner at port 58442
2021-05-20T19:32:42.330+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] The file lock is held by a different Gradle process (pid: 67494, lockId: 628651820260732672). Pinged owner at port 58442
Then kill -9 67494 terminates the owner and releases the lock.
Otherwise after a while gradle terminates with an error (stating here so it is easy to find):
* What went wrong:
Gradle could not start your build.
> Could not create service of type ResourceSnapshotterCacheService using GradleUserHomeServices.createResourceSnapshotterCacheService().
> Timeout waiting to lock file hash cache (/Users/myusername/.gradle/caches/6.9/fileHashes). It is currently in use by another Gradle instance.
Owner PID: 67494
Our PID: 68313
Owner Operation:
Our operation:
Lock file: /Users/myusername/.gradle/caches/6.9/fileHashes/fileHashes.lock

Related

Git installation failed [duplicate]

I am new here and i will try to explain my question kindly ignore any mistakes.
I am using git version git-2.8.2
It worked fine for one day then this problem occurs.
I am using gcloud repository.
First I tried gcloud clone command then this error occurs
Then to make sure git is there I tired git command then this error occurs
Then I double check by opening git Bash but same error was there too.
I tried reinstalling changing directory. but nothing works.
I face the same problem after I try to avoid memory leak in Windows 10. If you happened to change the regedit like me, just type regedit in the search then go to
HKEY_LOCAL_MACHINE -> SYSTEM -> ControlSet001 -> Services -> Null
change the value of Start to 1.
I accidentally bumped into the same problem when I was sorting out the services running on my computer with Windows 10.
fatal: open /dev/null or dup failed: No such file or directory
The reason was that I deleted the service named 'Null' that had no description as I thought that was a virus service.
Thus, when I found my git unable to operate, I reckoned the deleted service.
According to a solution provided on some site I tried to run the service again using cmd.exe
sc config Null start= system
sc start Null
but it said the service hadn't been existed in the list.
Thankfully, there are some kind folks who shares the information of the default services running on Windows 10 and the description necessary for the successful bringing back the service.
So as to get the service back in the list:
press Win + R
type regedit
go to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services section
Create Null folder and all the params it needs.
Restart your computer.
Now you got your Null service back and your git back as well.
Hope this helps.
I solved my problem accidentally. I would like to share it with everyone.
It was not a problem of git or gcloud or source tree.
Actually I have forcefully stooped windows update from installing which causes this problem.
Now when I install windows updates again this problem is fixed now.
Maybe this helps someone.
the similar situation in chrooted linux tree is fixable following way:
cd inside the folder where you are preparing the chroot dir, then
mount -o bind /dev dev/
then only chroot inside
I had this weird bug just now. I went back a dir and tried git init, it worked there.
I re-ran zsh and tried again in the dir it errored in originally and it worked. shrugs

Gradle :Could not create service of type FileHasher

I'm using Gradle to build a java project.
When I run any task (assemble, test).
I get randomly an error :
Could not create service of type FileHasher using
GradleUserHomeScopeServices.createCachingFileHasher()
Did any one had the same issue before?
Gradle V:3.5
java 8
I'm using the java plugin.
Thanks,
I was facing the same because I accidentally hit ctrl+z during build, and then the error was the same as yours.
I tried to remove the lock file but it didn't solve the problem.
Then I find all the process related to gradle by ps aux | grep gradle, and then kill -9 <pid> them all. The build backed to normal.
In your terminal type this:
./gradlew build
and the outcome would be:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type FileHasher using GradleUserHomeScopeServices.createCachingFileHasher().
> Timeout waiting to lock file hash cache (/Users/zra/.gradle/caches/4.1-rc-1/fileHashes). It is currently in use by another Gradle instance.
Owner PID: 17571
Our PID: 26055
Owner Operation:
Our operation:
Lock file: /Users/xxx/.gradle/caches/4.1-rc-1/fileHashes/fileHashes.lock
now do:
rm /Users/xxx/.gradle/caches/4.1-rc-1/fileHashes/fileHashes.lock
and build again.
P.S replace xxx with whatever username you've.
What worked for me was removing the lock file like suggested in the answer above: rm /Users/xxx/.gradle/caches/4.1-rc-1/fileHashes/fileHashes.lock and also killing the IDLE processes by running the command
./gradlew --status
It generates a list of gradle processes with status like
PID STATUS INFO
23580 IDLE 5.2.1
23860 IDLE 5.2.1
19058 STOPPED (stop command received)
Then kill one of the idle processes by kill <PID> and run the gradle build again.
One simple cause is that gradle daemon is not started with the same environment variable.
I had the same issue while changing the gradle user home.
Simply stop the daemon:
gradle --stop
change the ownership of .gradle/ using the following command:
sudo chown -R <USERNAME> .gradle/
I couldn't find this info elsewhere, posting in case it helps someone:
I had the same issue while running Android Studio on ChromeOS (on Chromebook).
I had shared a Google Drive folder with Linux (by selecting a folder, right-clicking and selecting Share with Linux) and created my project there. Build failed with this error, and removing the lock file did nothing for me.
Problem was resolved for me by re-creating the project under a 'Linux folder'.
If the OS is Windows.
Try this: gradlew build
Find de PID Process
And in CMD execute this command
TASKKILL /F /PID #PID
In my case, I was keeping the entire project in a folder managed by Google Drive Stream. Since that's a very rudimentary filesystem, Android Studio (or Git or Gradle, I can't tell which) was trying to do something on the FS that Google Drive Stream doesn't allow.
I simply moved the project onto my local drive and that fixed it!
I got the same error when I tried to execute ./gradlew from WSL2 ubuntu.
As suggested by #user16115, I stopped the running gradle in my host machine (windows machine) by issuing command gradlew.bat --stop.
After stopping the gradle in my host machine, I issued the same command ./gradlew in WSL2, gradle worked as expected.
ps: I have mounted my C:/ drive into WSL2 ubuntu.
This was same problem for me before some days and now only it's your or the user reading this solution.
Uninstall full android studio (means- 'after uninstall from control panel, delete folders of Android Studio,')
folders to be deleted:
C:\Program Files -> Android,
C:\Users{user folder name} -> .android & .gradle & {other folders related to Android Studio}
Reinstall form it's .exe and make sure your PC in connected with internet and with proper speed.
Download all SDK files as mention in that and keep downloading in Android Studio only. [do not download form other source- otherwise it will show errors, be careful]
Click on new project and select empty project and give the name and click on finish.
you will redirect to another window and than the main thing starts that is installation of GRADLE so for this you should have high connectivity of internet and that it will download automatically and and and now your are ready to go.
I had the same issue and the solution was to login with the correct user and then run gradle. I was logged in with a user that didn't had rights to run the tasks.
I just moved a project from Download folder (on Mac) to another one
If you try to build an inner project - try to go to root project and call
./gradlew <moduleName>:<command>
The easiest solution in my case wast to run
In case of linux
sudo ./gradlew bundleRelease
if windows then login with the user who has highest privileges.
Because this error occurred due to insufficient permissions

TFS build broken - The directory is not empty on sources directory

I am having a problem with my build (TFS2010). All has been well with this build recently until today where I am now getting an error pretty much as soon as the build starts:
Delete Sources Directory (00:00) The Directory is not empty.
I have looked on the server and I see \builds\1\myproject\sources\ is empty.. there is nothing in there at all! The error hints towards that not being the case, but it is empty for sure.
I wonder if it should not be empty in this case? Can anyone advise me on what course of action I might take on this to get the build running again?
This is the log of the failed build:
Overall Build Process
00:00
Update Build Number
00:00
Create the Drop Location
00:03
Run On Agent (reserved build agent Default Agent - server1)
00:00
Delete Test Results Directory
00:00
Delete Binaries Directory
00:00
Delete Workspace
00:00
Delete Sources Directory
The directory is not empty.
Many thanks for any help!
This usually happens if some other process has a handle on the file system. Explorer or a command prompt window is often the culprit.
I had come across this issue as one of the deployment folder in the "c:\" was openend. so close the folder and start your build will work. thanks
except case when there are somebody took handle to subdir or any file in this dir - such error can happens when there are files in directory (or in any subdirectory) which path length > 260 symbols. In such cases you need to delete '\\?\C:\mydir' instead of 'C:\mydir'. About 260 symbols limit you can read here.
Usually a file handle as mentioned above, although if you can't find the culprit deleting the "C:\agent_work\#NumberOfBuildDefinition#" will release this and mean the build can publish again.
This happens as your build definition, has a repository settings of "Clean" set to "true" and "Clean options" set to "Sources" so on every new build it's trying to remove all files from the folder in question.
For this problem, I just erase the deposit folder of the build that failed on the build server. I did not find anything in the event log.
This is valid for those who have chosen to copy the output of the generation into a folder on the build server.
My configuration: VS2015 / TFS2015
Build server: Windows Server 2008 R2

Git rename from index.lock to index failed

Using the GitHub Windows client I did a sync to pull remote changes to my local machine, but before finishing the sync, I ran out of disk space and the sync failed. Now I seem to have a bunch of local changes that are actually changes that were being pulled from origin. I tried to run git pull but got:
C:\Users\Tom\SourceLog [master +4 ~26 -0 !]> git pull
Updating b3a86e1..5afd74f
error: Your local changes to the following files would be overwritten by merge:
SourceLog.Interface/IChangedFile.cs
SourceLog.Interface/ILogEntry.cs
...
Please, commit your changes or stash them before you can merge.
error: The following untracked working tree files would be overwritten by merge:
Lib/MSBuildExtensionPack/4.0.6.0/Ionic.Zip.dll
Lib/MSBuildExtensionPack/4.0.6.0/MSBuild.ExtensionPack.dll
...
Aborting
So now I'm trying to discard the local changes but I'm getting:
C:\Users\Tom\SourceLog [master +4 ~26 -0 !]> git checkout -- .
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) y
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) n
fatal: unable to write new index file
How can I clean this up? (I didn't have any local changes before starting the sync.)
Update
Can't seem to reset head..
C:\Users\Tom\SourceLog [master +4 ~0 -0 !]> git reset head
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) y
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) n
error: Could not write new index file.
fatal: Could not reset index file to revision 'head'.
Looks like the following process had a lock on the .git\index file:
ssh-agent.exe
C:\Users\Tom\AppData\Local\GitHub\PortableGit_8810fd5c2c79c73adcc73fd0825f3b32fdb816e7\bin\ssh-agent.exe
I killed the process and ran git reset HEAD and looks like I'm back to normal now.
In my case, this was caused by using the same Git repo from both admin and non-admin command prompts. When last git pull was from admin cmd, the index was created by it, and then non-admin cmd had insufficient permissions to modify it.
My solution was re-creating the index (while keeping the worktree intact):
del .git\index
del .git\index.lock
git reset --mixed head
In my case I had to close the VS code which I opened with code . from a WSL Ubuntu terminal.
It can be a real issue, try to run your Terminal as Administrator instead of user. Worked for me
I was seeing this Rename from '.git/index.lock'... message when attempting to execute
git checkout -b my-branch
The fix for me was to run the command line as admin.
Specifically I was using the excellent cmder application as a non-admin, which resulted in the rename message appearing. By running cmder as an admin, then performing the checkout again, it worked fine.
Git 2.10 (Q3 2016, 4 years later) should improve the situation on Windows
See commit 05d1ed6 (23 Aug 2016) by Ben Wijen (Ben).
mingw: ensure temporary file handles are not inherited by child processes
When the index is locked and child processes inherit the handle to
said lock and the parent process wants to remove the lock before the
child process exits, on Windows there is a problem: it won't work
because files cannot be deleted if a process holds a handle on them.
The symptom:
Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed.
Should I try again? (y/n)
Spawning child processes with bInheritHandles==FALSE would not work
because no file handles would be inherited, not even the hStdXxx handles in STARTUPINFO (stdin/stdout/stderr).
Opening every file with O_NOINHERIT does not work, either, as e.g. git-upload-pack expects inherited file handles.
This leaves us with the only way out: creating temp files with the O_NOINHERIT flag. This flag is Windows-specific, however.
For our purposes, it is equivalent to O_CLOEXEC (which does not exist on
Windows), so let's just open temporary files with the O_CLOEXEC flag and
map that flag to O_NOINHERIT on Windows.
To discard local changes, go
git reset HEAD
Then checkout your old commit, delete the new one, and pull again.
git checkout "hashOld"
git branch -d "hashNew"
git pull
For me it was this error:
Rename from 'D:/dev/repo/.git/refs/remotes/origin/my-branch.lock' to 'D:/dev/repo/.git/refs/remotes/origin/my-branch' failed. Should I try again? (y/n)
Renamed "my-branch" file, retried, and "my-branch.lock" succeed in renaming, not sure if this is correct, but worked. Local changes in both master and my-branch were preserved.
I got this error several times in a row when running git reset HEAD in a project stored in a Google Drive folder, but after a few minutes the problem went away.
I removed index and index.lock (in the .git folder) and ran git checkout . to undo the changes and resolved, but if I wanted to commit the changes I would have run git add -A after git commit -m "description"
I ran into this issue and wanted to post the answer for future searchers. Windows confirmed only. I got this when my git repository was under a directory that requires elevated permissions, AND I was running git from a process(cmd.exe) that did NOT have permissions to write to that folder, thus it could not clear the lock.
The answer is simple, run as admin.
I've answered this on a similar question. Might help others too, quoting the same here:
"For if any windows user stumbles on this:
I faced same issue and it wasn't solved by permissions since I had all the permissions assigned. Removing index.lock didn't help either.
I tried with WSL and it showed this error:
Another git process seems to be running in this repository.
Based on this I quit every process run by VS Code (that is the IDE I am using) and voila everything back to normal.
Note: Merely closing VS Code didn't help, had to end all processes from task explorer.
On a larger point, try ending all the processes via which you were using git. For me it was just VS Code."
Original answer: https://stackoverflow.com/a/67615831/13404308
I had a similar issue with Git. The solution for me was to delete the solution locally through windows explorer, and then re-clone the repository. This removed all the files that were stored locally on my machine, and resulted in the
Rename from '.git/..' to '.git/..' failed. Should I try again? (y/n) y
going away. After I cloned the respository, I tried my command again(which in my case was GIT COMMIT) and the failure did not reoccur.
The issue came about when I was trying to resolve a merge conflict that was happening after merging a feature branch into the develop branch.
Either kill the process that is locking the file or if it is a new repo, del the .git folder rm -rf .git and start again with git init
I'm using Tortoise Git. I just opened a new Windows Explorer and it fixed this. (For command line Git maybe just open a new shell).
I had seem issue when I was rebase my branch with master. My solution is turn off all solution which are opening and reset hard my branch to origin and rebase again.
git init resolved my problem. I was getting below issue.
Rename from '.git/objects/pack/pack-XXXXX.pack' to '.git/objects/pack/old-XXXXX.pack' failed. Should I try again? (y/n)
This is caused when antivirus or OS defender (for example Windows Defender) is running.
The solution: turn off antivirus for several minutes make your add, commit and push.
Turn on antivirus.
It will work.
In my case, I had done a git pull as Admin, and my regular user no longer had sufficient permissions.
My solution was to reset ownership to my regular user.
Right-click on .git, and open Properties.
On the Security tab, click Advanced.
In Advanced Security Settings, next to Owner, click Change (even if it's already correct).
In Select User, select the regular user, and click Okay.
On the Security tab, under Owner, you now have a Replace owner of subcontainers and objects checkbox - Check this and click Okay.
I tried a lot of suggestions. At times, a commit would succeed, but then the error returned. At last, pausing Dropbox sync seems to have done the trick! I have no clue how Dropbox sync could cause this error for longer than a few moments (the time required to sync my 24K .git/index).
For my case, it was just Windows Explorer being open and it was opening the directory above the directory that I wanted to rename. After closing Windows Explorer, issue went away immediately.
I was using Bash Git as Administrator.
in my case, I was using vim on WSL and writing git command on Powershell so I quit vim and then I was able to switch branches
Restart your Source Code editor; killing a Process may work but is not polite_
I copied (in Windows 10) the whole project to a new folder. Pushed from there to the origin (at that no index problem issued). Then I returned back to the project directory, where the problem occured. Deleted .git directory. Initialized anew (git init). Added to the index (git add . ). Fetched from the remote origin and merged. That's all there is to it.
I change project permission
Then, I exit Code Editor

Changing the user executing the build script in Atlassian Bamboo

Here is my problem:
I have a python build script building a .air package and deploying it on a server. If I run this script from a cmd.exe window, there is no problem, the files are correctly created and deployed.
But I would like to use Bamboo to be able to build my app everytime I commit/push changes. I configured it but have a serious problem: the .air package is created but the deployment (with a fabric script) doesn't finish... I noticed that the process is launched by 'Administrator' in a cmd.exe and by SYSTEM trough Bamboo. I think that this is the problem (maybe SYSTEM cannot find the ssh host or whatever), so I wanted to know if someone knows how to change the user executing the script to 'Administrator'.
Yes, you can change the user that your bamboo server runs as. I recently posted an answer with details on how do just that in Windows Mercurial global keychain . All the documentation for the windows stuff in the wrapper file can found at http://wrapper.tanukisoftware.com/doc/english/props-nt.html .

Resources