Git - 解除文件.idx和.pack的链接失败（该文件唯一的进程所有句柄是git.exe）

Question

请看这张图片！ Git会如此愚蠢吗？Git无法取消链接某个文件，但只有git.exe在持有该文件的句柄。 （权限正常-完全控制） 请问，是否有安全的解决方案来解决这个问题？ 我的Git版本是1.9.5-preview20141217。

- plaurinc

---

也许有人在文件上（或导致文件的子目录上）搞砸了权限，以至于当前运行 git 的用户没有删除它的权限... - twalberg

嗨，我检查了所有权限，管理员拥有“完全控制权”，而且我是这台机器上的管理员。 - plaurinc

你好，这个问题有解决方案吗？我也遇到了同样的问题。 - James Mart

嗨，现在我有一台新电脑，没有这个问题了。所以也许解决方法是将git存储库检出到新文件夹中，或者可能是更新的git版本修复了它。 - plaurinc

这应该不再发生，因为 Git 2.19（2018 年第三季度）已经解决了此问题。请参见下面的回答。 - VonC

Answer 1

我曾经遇到过这个问题，通过运行命令：git gc 解决了它。上述命令会删除临时和不必要的文件（垃圾回收器）：https://dev59.com/OG855IYBdhLWcg3wXC9-#26229658

- Grzegorz Smulko

Answer 2

Git 2.19 (Q3 2018)改进了打包文件的文件描述符管理，并避免了“Unlink of file... failed. Should I try again?”错误消息。

请参见提交12e73a3（由Kim Gybels (dscho)于2018年7月9日提交）。
^{（由Junio C Hamano -- gitster --于2018年8月2日合并至提交562413e）}

gc --auto: 在自动打包之前释放打包文件

"git gc --auto"在生成"git repack/prune"之前会打开packfiles的文件描述符，这会让Windows系统感到不安，因为它不希望一个进程正在操作被另一个进程打开的文件。为了避免删除文件时出现故障，请教授gc --auto在自动打包存储库之前释放pack文件。同时，当自动打包存储库不再触发时，请让测试“使用自动GC获取不会锁定”发出警告。这解决了Git for Windows问题“取消链接文件XXX失败。我应该重试吗？”，使用PR 1769。

---

另一项改进：随着 Git 2.34（2021 年第四季度）的推出，运行命令 API 已经更新，以便调用者可以在触发 auto-gc 的命令生成之前轻松要求关闭打包文件的文件描述符。

请参考提交 c4dee2c, 提交 5a22a33, 提交 28d04e1, 提交 3322a9d (2021年9月9日)和提交 7e44ff7, 提交 957ba81 (2021年9月8日)，作者是Johannes Schindelin (dscho)。
^{(合并于Junio C Hamano -- gitster --的提交 c042ad5，2021年9月20日)}

c4dee2c085:更靠近生成子进程的关闭对象存储

^{由 Johannes Schindelin 签署}

在许多情况下，我们生成可能触发重新打包的子进程时，会先显式地关闭对象存储（这样 repack 进程就可以删除 .pack 文件了，否则在 Windows 上无法删除文件，因为只要文件仍在使用中，它们就不能被删除）。

现在，我们尽可能使用 run_command() API 的新功能 close_object_store，以进一步延迟关闭对象存储。
这使得代码更易于维护，因为现在更明显的是，我们只释放那些文件句柄是因为那些子进程。

- VonC