23

Running version 1.9.4.msysgit.0 of git, I'm getting the mentioned error(s) almost every time I run git gc on the command-line or via git gui when it prompts me to "compress loose objects":

Counting objects: 1110956, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (269562/269562), done.
Writing objects: 100% (1110956/1110956), done.
Total 1110956 (delta 636114), reused 1110956 (delta 636114)
Unlink of file '.git/objects/pack/pack-207f1feb5376880778637c ... 8371cea62.pack'
    failed. Should I try again? (y/n) n
Checking connectivity: 1110956, done.

The only solution seems to be hitting n for each of the locked files - as suggested by this thread:

Short answer: hit 'n' to get through all of those, and then manually run "git gc".

The thread also suggests that...

The problem is that the files are held open by a parent git.exe of the one that's trying to do the gc.

...which, when looking at the process tree, is entirely plausible:

git process tree

My question is, is there something I can do to prevent this? It's getting really annoying having to do this multiple times a day... And why does it happen? Is it a git/w32-only bug?

Update 1: To clarify - after hitting n several times as described, git gc finishes and the local repository is "clean", i.e. re-running git gc will not cause said file lock problems anymore - but this is only for some time. After working sometime on the repo – sometimes after minutes, sometimes after hours – the repository is "dirty" again and the described problems prevail. Running git gc from within git-bash instead of cmd as suggested by CodeWizard does not help. He further suggested that other non-git software might be holding the locks in question. I am skeptical of that, not least due to the comment in thread linked above – I think a parent git process is holding the locks – but I still have to verify that claim.

Update 2: Turns out that CodeWizard was right all along - at least in my case it was indeed the IDE locking on those files... So it's an issue of the EGit Team Provider for Eclipse, and not git itself.

enter image description here

Update 3: To find locked files, you can for example use one of these free tools:

In both of these, use CTRLF to bring up the "Find Handle" dialog.

Madacol
  • 3,611
  • 34
  • 33
zb226
  • 9,586
  • 6
  • 49
  • 79
  • 1
    Good tip finding open handles - I used Process Explorer, killed the offending process and re-ran "git gc" – Mark Larson Aug 20 '15 at 20:08
  • Good point, I've added a link! – zb226 Aug 20 '15 at 20:31
  • At least with Win7, attempting to delete the file itself from the explorer will say what process has the lock on the files (most times). It led me to find out that eclipse had it all along. – Jeff Mercado Sep 22 '16 at 00:59
  • Possible duplicate of [Unlink of file Should I try again?](http://stackoverflow.com/questions/4389833/unlink-of-file-should-i-try-again) – Jim Fell Dec 20 '16 at 15:29
  • 1
    Note: Git 2.19 should improve the situation: https://stackoverflow.com/a/51755262/6309 – VonC Aug 09 '18 at 07:31

2 Answers2

1

What I recommend you to do is to use git from the git-bash (i.e. %GIT_HOME%\bin\bash.exe) and not from cmd. Once switching to git-bash you should not expect to get this problem since cmd is a Windows command that might lock your files, while git-bash is like a UNIX emulator which will not lock your files (even if it's actually looking on your Windows folders).

zb226
  • 9,586
  • 6
  • 49
  • 79
CodeWizard
  • 128,036
  • 21
  • 144
  • 167
  • 11
    But I get the same when using git bash – Musa Haidari Feb 15 '15 at 05:41
  • 1
    execute `git fsck` and tell me what u get – CodeWizard Feb 15 '15 at 06:22
  • 1
    $ git fsck **** Checking object directories: 100% (256/256), done. **** Checking objects: 100% (9818/9818), done. **** dangling blob d6d88f16abdcb567c46f4d38174a5d9ce136530d – Musa Haidari Feb 15 '15 at 09:31
  • 3
    That's the corrupted data: d6d88f16abdcb567c46f4d38174a5d9ce136530d its a "zombie" file which is not commite, try git gc --aggressive and see if it helps. if not try to delete this blob and execute the fsck + gc again, – CodeWizard Feb 15 '15 at 09:39
  • I run the mentioned command, I did not get the questioned promped, but dangling blob did not solved. However `git gc --prune="0 days"` solved it. Reference: http://stackoverflow.com/questions/9955713/git-dangling-blobs – Musa Haidari Feb 15 '15 at 10:02
  • 1
    Good, you instructed git to get rid of all the dangling files older then the last day. :-) – CodeWizard Feb 15 '15 at 10:10
  • @jsexpert: Thanks for answering - unfortunately, like @Musa, I'm also getting those locks when using `git-bash`, so I still have to consider this an unsolved issue. – zb226 Feb 16 '15 at 12:23
  • Here is what you can try to fix it. clone the repository to a new folder then compare the content of the 2 folders (with external tool like beyond compare etc) and copy the change to the new "good" repository, see if this help. – CodeWizard Feb 16 '15 at 12:31
  • If you are both on windows it means that someone still "capture" the repo (ide, 3rd party tool etc). try to find out which process is the evil one. you can use a software im using process explorer https://technet.microsoft.com/en-us/sysinternals/bb896653. find out the evil process and kill it – CodeWizard Feb 16 '15 at 12:33
  • @jsexpert: OK, since this conversation is getting a bit convoluted in the comments, I've updated the question with regard to your last comments. Thanks for your continued input! – zb226 Feb 17 '15 at 09:35
  • Hi there,can you try and update your git installation to the latest version and check to see if it still happen? – CodeWizard Feb 17 '15 at 12:42
  • @jsexpert: Yes, I've just updated to the most recent, maintained version `1.9.5.msysgit.0` - I will report back what happens... By the way, when replying with a comment to your own answer, please add @zb226 - otherwise I won't get notified that you have replied! – zb226 Feb 18 '15 at 10:52
  • @jsexpert: You were right, it's the IDE... should've checked that myself earlier - I was just too confident that the people in the cited thread were right. Mea culpa :) You might want to remove the `git-bash` part of your answer though, as this has been proven not to help. And thanks again! – zb226 Feb 18 '15 at 13:28
0

Check if another process is not locking the file. In my case I just had to close an Eclipse instance that had a project open from tha git repository for which "git gc" was run.

Radek
  • 123
  • 10