Unlink of file failed

Question

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.

Just a side note: I have had this issue when trying to reset --hard and found that adding and committing files to your local repository before the reset had worked. — PJT, Aug 27 '13 at 16:29
I think I had this problem because I had angle brackets in my branch name. I've mailed git hub support to find out if that is a bug. — Zephyr was a Friend of Mine, Aug 27 '14 at 14:08
There are quite a few too many possible answers to this question, so whilst it was helpful for me, I cannot but vote to close. — Puppy, Dec 31 '14 at 17:29
Guys, there is no unlink, or chmod command on Windows. I wonder what are you talking about? There is no excuse for git failing to read answer from a user. I am suffering the same issue... — Martin Dobšík, Mar 30 '16 at 07:54

VonC · Accepted Answer · 2019-01-28T23:08:23.137

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)"

In my case it was Skype. I'd earlier transferred the file to others and some had not yet accepted or cancelled. — Vivek Kodira, Sep 11 '13 at 07:20
I found Windows Explorer to be the culprit. It was most likely because of TortoiseGit's icon overlays or TGitCache. Closing all open folders did the trick, but you may only need to close the project folder if that's open. — Allan Bogh, Aug 25 '14 at 15:38
In my case it was VS2013 as it was bound to the open solution. — BrotherOdin, Oct 21 '14 at 13:00
Explorer.exe was my problem - I don't have TortoiseGit. I killed explorer.exe from Task Manager and spawned a new one using CTRL-ALT-DELETE => Task Manager => File => Run New Task => "explorer.exe" (without the quotes) — joehanna, Jul 27 '15 at 01:20
In my case it is purely a git problem. I find no other program having that file open (Using elevated process explorer). I even updated to git 2.8. — Martin Dobšík, Mar 30 '16 at 08:28
Bumping up a very old thread here, but from the above issue link there's a temporary workaround by invoking `git gc` to force GC before trying the pull again. Of coursse, it works out of the box with the update.. Just saying. :) — varevarao, Sep 28 '16 at 12:13
@varevarao interesting. Don't hesitate to propose an edit to this answer. — VonC, Sep 28 '16 at 12:14
In my case I had to processes with the name null. After I shut down both processes, git pull worked again. — Codev, Feb 25 '19 at 14:52

score 65 · Answer 2 · answered Sep 05 '12 at 11:06

65

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.

answered Sep 05 '12 at 11:06

NeilD

2,278
3
24
28

4

I hit this problem on Windows 7 when doing a pull and git did an auto pack. It complained on the "idx" files. I then opened a console window as an admin and ran a git gc and there was no problem. So this is a good solution. – grahamesd Aug 23 '14 at 12:39
1

git gc did it for me on Windows 7. It happened b/c I was doing a git pull on cmder while doing a push on WebStorm – Alessandro Jun 01 '15 at 20:21
2

Wow. Thanks NeilD. It fixed it for me too. It would be nice to port GIT to Windows a bit more. – Martin Dobšík Mar 30 '16 at 08:31
Well... it was needed 6 years ago. Now? Who knows? ¯\_(ツ)_/¯ – NeilD Jul 12 '18 at 07:51

score 31 · Answer 3 · answered Jun 04 '14 at 19:44

31

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.

answered Jun 04 '14 at 19:44

Paul Nikonowicz

3,883
21
39

4

Similar for me. Eclipse needed to be closed before running git gc. – alfoks May 13 '15 at 09:47

score 5 · Answer 4 · answered Apr 24 '15 at 09:17

5

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.

answered Apr 24 '15 at 09:17

Garrett Smith

688
1
7
24

score 2 · Answer 5 · answered May 30 '14 at 10:31

2

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

answered May 30 '14 at 10:31

Arvind Bhardwaj

5,231
5
35
49

score 2 · Answer 6 · answered Apr 30 '15 at 15:55

2

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

answered Apr 30 '15 at 15:55

Bikey

935
7
12

score 2 · Answer 7 · answered Jul 28 '16 at 06:37

2

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

answered Jul 28 '16 at 06:37

Md. Naushad Alam

8,011
6
25
23

score 1 · Answer 8 · answered Jun 12 '12 at 03:15

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.

score 1 · Answer 9 · edited Aug 28 '12 at 13:56

1

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

edited Aug 28 '12 at 13:56

ЯegDwight

24,821
10
45
52

answered Aug 28 '12 at 13:35

Sebastian Thomas

1,245
13
20

score 1 · Answer 10 · answered Feb 01 '19 at 11:08

1

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]

answered Feb 01 '19 at 11:08

Juha Hanka

639
6
5

score 0 · Answer 11 · answered Mar 01 '13 at 04:22

0

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

answered Mar 01 '13 at 04:22

Envil

2,687
1
30
42

score 0 · Answer 12 · answered Dec 05 '13 at 14:03

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.

score 0 · Answer 13 · answered Nov 02 '15 at 14:24

0

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

answered Nov 02 '15 at 14:24

Tisch

2,598
4
27
34

score 0 · Answer 14 · answered May 09 '17 at 18:27

0

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!

answered May 09 '17 at 18:27

In-young Choung

779
2
8
22

score 0 · Answer 15 · answered Oct 16 '19 at 13:34

0

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

answered Oct 16 '19 at 13:34

Harshad Sindhav

171
2
7

score 0 · Answer 16 · answered Nov 07 '19 at 17:04

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

Alien · Answer 17 · 2020-01-03T12:20:58.083

0

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

edited Jan 03 '20 at 12:20

answered Jan 03 '20 at 03:44

Alien

15,141
6
37
57

score 0 · Answer 18 · answered Feb 28 '22 at 10:44

0

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.

answered Feb 28 '22 at 10:44

Milind D

314
2
3

Unlink of file failed

18 Answers18

`gc`/`repack`: release packs when needed

`fetch`: release pack files before garbage-collecting

Make sure temporary file handles are not inherited by child processes

Linked

Unlink of file failed

18 Answers18

gc/repack: release packs when needed

fetch: release pack files before garbage-collecting

Make sure temporary file handles are not inherited by child processes

Linked

`gc`/`repack`: release packs when needed

`fetch`: release pack files before garbage-collecting