我可以/应该怎么处理这个 git gc 错误？（rm：无法取消链接包权限被拒绝）
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10461870/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What can/should I do about this git gc error? (rm: cannot unlink pack Permission denied)
提问by danludwig
When running git gc, I keep seeing this error:
运行 git gc 时，我一直看到这个错误：
rm: cannot unlink 'pack-30b1ff2[reset of hash].pack': Permission denied
What can/should I do about this error?
我可以/应该对这个错误做什么？
Update
更新
Sorry, I should have provided more info. Yes, I have tried a reboot. In fact,reboots have fixed gc issues for me before.
抱歉，我应该提供更多信息。是的，我试过重启。事实上，重启之前已经为我解决了 gc 问题。
I only noticed this issue because when I open Git Gui, it prompts me now and then to compress the database. I eventually noticed that after a couple of times opening Git Gui that it kept prompting me, even though I clicked Yes, and it came back "successful".
我只是注意到这个问题，因为当我打开 Git Gui 时，它会时不时地提示我压缩数据库。我最终注意到，在打开 Git Gui 几次后，它一直提示我，即使我点击了是，它又“成功”了。
So then I tried running it with Git EXT's Settings - Git maintenance - Compress git database command. This command told me that there was an error (red light in Git EXT whereas there was a green light in Git Gui).
然后我尝试使用 Git EXT 的设置 - Git 维护 - 压缩 git 数据库命令运行它。这个命令告诉我有一个错误（Git EXT 中的红灯，而 Git Gui 中的绿灯）。
The error I posted above however was from running git gc straight from git bash.
然而，我在上面发布的错误是直接从 git bash 运行 git gc 的。
Should I schedule a disk scan? Could bad sectors be causing this? I was hoping this would be a quick answer :(
我应该安排磁盘扫描吗？坏扇区会导致这种情况吗？我希望这会是一个快速的答案:(
采纳答案by Dmitry Ovsyanko
"Permission denied" on Windows is often caused by a lock from a running process. It's probable that there is a stalled Git EXT thread opened the pack file.
Windows 上的“权限被拒绝”通常是由正在运行的进程锁定引起的。很可能有一个停滞的 Git EXT 线程打开了包文件。
Try to do the git gcin safe mode.
尝试git gc在安全模式下进行。
Another option is to clone the repository in a new place and delete the old one.
另一种选择是将存储库克隆到新位置并删除旧存储库。
回答by schoetbi
In my case it was TortoiseGit. To solve the problem I opened TortoiseGit Settings->Icon Overlays and set the Status cache to "None". Now the process TGitCache ended, so that all objects are "free" to be processed by git gc.
就我而言，它是 TortoiseGit。为了解决这个问题，我打开 TortoiseGit Settings->Icon Overlays 并将状态缓存设置为“无”。现在 TGitCache 进程结束，因此所有对象都“空闲”以供 git gc 处理。
回答by Patrick Desjardins
You need to close your console where the command that locked the command occurs. This could be VI that is locking the file or any command that was killed. The easiest solution is to close everything and reopen. You should be able to execute the command without problem.
您需要关闭发生锁定命令的命令的控制台。这可能是锁定文件的 VI 或任何被终止的命令。最简单的解决方案是关闭所有内容并重新打开。您应该能够毫无问题地执行命令。
回答by VonC
Git 2.23 (Q3 2019) should avoid a permission denied issue during gcbecause of the commit graph (introduced in Git 2.18), which does precompute and store information necessary for ancestry traversal in a separate file to optimize graph walking.
Git 2.23（2019 年第 3 季度）应该避免gc由于提交图（在 Git 2.18 中引入）而导致的权限被拒绝问题，它会预先计算并将祖先遍历所需的信息存储在单独的文件中以优化图遍历。
With Git 2.23, the commit-graph file is part of the "files that the runtime may keep open file descriptors on, all of which would need to be closed when done with the object store", and the file descriptor to an existing commit-graph file now is closed before"gc" finalizes a new instance to replace it.
在 Git 2.23 中，提交图文件是“运行时可能会保留打开文件描述符的文件的一部分，所有这些文件在对象存储完成后都需要关闭”，以及文件描述符到现有提交 -图形文件现在在“gc”完成一个新实例以替换它之前关闭。
See commit 2d511cf, commit 5472c32, commit c3a3a96(17 May 2019) by Derrick Stolee (derrickstolee).
(Merged by Junio C Hamano -- gitster--in commit 5cb7c73, 09 Jul 2019)
请参阅Derrick Stolee ( ) 的commit 2d511cf、commit 5472c32、commit c3a3a96（2019 年 5 月 17 日）。（由Junio C Hamano合并-- --在commit 5cb7c73，2019 年 7 月 9 日）derrickstoleegitster
packfile: close commit-graph inclose_all_packsThe
close_all_packs()method is used to close all read handles to pack-files and the multi-pack-index before running 'git gc --auto'.
This is particularly important on the Windows platform, where read handles block any writes to those files.
Replacing one of these files with arename()will fail in this situation.The commit-graph also performs a rename, so is susceptable to this problem.
We are careful to close the commit-graph before writing, but that doesn't work when a 'git fetch' (or similar) process runs 'git gc --auto' which may write a commit-graph.Here, close the commit-graph as part of
close_all_packs().
packfile: 关闭提交图close_all_packs该
close_all_packs()方法用于在运行 'git gc --auto'之前关闭包文件和多包索引的所有读取句柄。
这在 Windows 平台上尤为重要，在 Windows 平台上，读取句柄会阻止对这些文件的任何写入。在这种情况下，
用 a 替换这些文件之一rename()将失败。提交图还执行重命名，因此容易出现此问题。
我们在写入之前小心地关闭提交图，但是当“git fetch”（或类似）进程运行git gc --auto可能会写入提交图的“ ”时，这不起作用。在这里，关闭提交图作为
close_all_packs().
