git gc / git gui：取消连接文件<内部包文件名>失败 [英] git gc / git gui: Unlink of file <internal pack file name> failed

问题描述

运行版本 1.9.4.msysgit.0 git ，我收到提到的错误）几乎每次在命令行上运行 git gc ，或者通过 git gui ，当它提示我压缩松散的对象：

 计数对象：1110956，完成。 
使用多达4个线程的Delta压缩。 
压缩对象：100％（269562/269562），完成。 
写入对象：完成100％（1110956/1110956）。 
总计1110956（增量636114），重新使用1110956（delta 636114）
取消文件'.git / objects / pack / pack-207f1feb5376880778637c ... 8371cea62.pack'
失败的链接。我应该再试一次吗？ （y / n）n 
检查连接：1110956，完成。 
  

唯一的解决方案似乎是为每个锁定的文件打到 n - 根据所建议的，没有帮助。他进一步建议其他非 git 软件可能会持有该锁。我对此表示怀疑，尤其是由于在&ndash之上链接的评论;我认为一个父级 git 进程正在拿着锁–但是我仍然需要验证该声明。

更新2：原来（现在是微软的产品）

进程黑客（现在，在我的工具集中替换Process Explorer）

在这两个中，使用 CTRL F 打开查找句柄对话框。

解决方案

我建议你做的是使用 git-bash 中的 git 即％GIT_HOME％\bin\bash.exe ）而不是从 cmd 。
一旦切换到 git-bash ，您不应该期望得到这个问题，因为 cmd 是一个Windows命令这可能会锁定您的文件，而 git-bash 就像一个UNIX模拟器，不会锁定您的文件（即使它实际上是在您的Windows文件夹上）。

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:

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 jsexpert 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 jsexpert 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.

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

• Process Explorer (by now, a Microsoft offering)
• Process Hacker (by now, replaced Process Explorer in my toolset)

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

解决方案

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

这篇关于git gc / git gui：取消连接文件<内部包文件名>失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！