Unlink of file failed

I'm trying to do a git pull and I get the following error:

>Unlink of file 'lib/xxx.jar' failed. Should I try again? (y/n)

No matter if I select y or n it's not possible to get to a state where I can pull or push.

That usually means a process is still using that specific file (still has an handle on it)
(on Windows, ProcessExplorer is good at tracking that kind of process)

Try closing your other programs, and try again your git pull.

Note that you have an alternative with the GIT_ASK_YESNO variable.

---

Update January 2019:

That should be even more fixed, with Git 2.21 (Q1 2019), as "git gc" and "git repack" did not close the open packfiles that they found unneeded before removing them, which didn't work on a platform incapable of removing an open file.
This has been corrected.

See commit 5bdece0 (15 Dec 2018) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 5104f8f, 18 Jan 2019)}

> ## gc/repack: release packs when needed

> On Windows, files cannot be removed nor renamed if there are still handles held by a process.
To remedy that, we introduced the close_all_packs() function.

> Earlier, we made sure that the packs are released just before git gc is spawned, in case that gc wants to remove no-longer needed packs.

> But this developer forgot that gc itself also needs to let go of packs, e.g. when consolidating all packs via the --aggressive option.

> Likewise, git repack -d wants to delete obsolete packs and therefore needs to close all pack handles, too.

---

Update January 2016

That should be fixed in Git 2.8 (March 2016) (and see Git 2.19, Q3 2018 below)

See commit d562102, commit dcacb1b, commit df617b5, commit 0898c96 (13 Jan 2016) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 3c80940, 26 Jan 2016)}

> ## fetch: release pack files before garbage-collecting

> Before auto-gc'ing, we need to make sure that the pack files are released in case they need to be repacked and garbage-collected.

> Many codepaths that run "gc --auto" before exiting kept packfiles mapped and left the file descriptors to them open, which was not friendly to systems that cannot remove files that are open.
They now close the packs before doing so.

That fixes git-for-widows issue 500.

Looking at the test used to validate that new approach, a possible workaround (since Git 2.8 is not yet out) would be to raise artificially gc.autoPackLimit.

git config gc.autoPackLimit 10000
git fetch
git config gc.autoPackLimit 50 # default value

---

git 2.8.4 (June 2016) does mention issue 755 which should also alleviate the issue (commit 2db0641):

> ## Make sure temporary file handles are not inherited by child processes

---

Actually, git-for-windows issue 500 mentioned above is really fixed with Git 2.19, Q3 2018.
See "Git - Unlink of file .idx and .pack failed (The only process owned handle to this file is git.exe)"

This is a Windows specific answer, so I'm aware that it's not relevant to you... I'm just including it for the benefit of future searchers.

In my case, it was because I was running Git from a non-elevated command line. "Run as Administrator" fixed it for me.

For me, it was because Visual Studio was trying to reload all of the changed files from the pull. Have visual studio refresh, then run git gc.

On Windows using GitHub for Windows, I got a similar error in the shell when running git gc:

Unlink of file '.git/objects/pack/pack-0b40ae7eae9b83edac62e19c07ff7b4c175244f6.idx' failed. Should I try again? (y/n)

I solved it by closing the GitHub GUI.

Try to restart you Apache or other web server as it may have locked some of your files.

Closed Visual Studio and Rubymine and didn't get the error again. One of them was the culprit.

Close your IDE then do git pull . It will work.

I've got this problem too, but I found out it was the UltraEdit in the way, since I used UE to organize and edit my eclipse workspace~~

Maybe because the UE has a handle on the old version of specific file, Git could not unlink of it.

After I closed UltraEdit, the problem never happened again.

This was caused in my case by SimpLESS, the LESS compiler. You have to close it in the systray.

None of the above answers ain't work for me, but I run git gc command with force option, and it solved my case.

'git gc --force'

[Windows 7, Run As Administrator => Command Prompt]

The problem is because you're having some program that handling these files. I have an suggestion that you should use the Unlocker to find the program that's handling it:

Unlocker

I have had this happen on Windows XP, both with the message stuck in a loop, and being able to be cleared by replying.

The stuck-in-a-loop occurence was cleared by closing the Git-GUI. (I was running git merge -i in a bash shell.)

The other occurences happened possibly due to the large number of files in my repository. It happened mainly with .cod files, which I later exclude from version control. (I do have a reason for intially tracking them.) I believe the cause might be related to the rate at which Git uses file handles.

I wonder if the able-to-be-cleared-by-replying problem is Windows related, as two previous posters have mentioned Windows, and no one has said they have the problem with other operating systems.

I had PHPStorm open, closed that and all was well.

I had the same issue and I closed all the related programs from Window Task Manager. However, it was still not working. The interesting part is that I ran "Git rebase" instead of "Git pull" and it worked!

Try running command line editor in administrative mode and run command. It helps and solves problem. :)

In my case I had an old method of pruning tags causing the issue. I solved it by unsetting the original:

git config --global --unset remote.origin.fetch '\+refs/tags/\*:refs/tags/\*'

then adding this to prune deleted branches on the server:

git config --global fetch.pruneTags true

I faced the same error and resolved it by closing the eclipse and pulling again as the file was being used.

I had the same issue on windows. I was trying to run gc on windows while the file was being accessed on my Ubuntu VM. Closed Terminator and File explorer on Ubuntu worked for me.