windows 取消文件链接失败
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10181057/
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
Unlink of file failed
提问by marko
I'm trying to do a git pull and I get the following error:
我正在尝试执行 git pull ，但出现以下错误：
Unlink of file 'lib/xxx.jar' failed. Should I try again? (y/n)
取消文件“lib/xxx.jar”的链接失败。我应该再试一次吗？(是/否)
No matter if I select y or n it's not possible to get to a state where I can pull or push.
无论我选择 y 还是 n 都不可能达到我可以拉或推的状态。
回答by VonC
That usually means a process is still using that specific file (still has an handle on it)
(on Windows, ProcessExploreris good at tracking that kind of process)
这通常意味着进程仍在使用该特定文件（仍然有一个句柄）
（在 Windows 上，ProcessExplorer擅长跟踪那种进程）
Try closing your other programs, and try again your git pull.
尝试关闭您的其他程序，然后再试一次您的git pull.
Note that you have an alternative with the GIT_ASK_YESNOvariable.
请注意，您可以使用GIT_ASK_YESNO变量。
Update January 2019:
2019 年 1 月更新：
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.
在 Git 2.21（2019 年第一季度）中，这应该更加固定，因为“ git gc”和“ git repack”在删除之前没有关闭他们发现不需要的打开包文件，这在无法删除打开文件的平台上不起作用。
这已得到纠正。
See commit 5bdece0(15 Dec 2018) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster--in commit 5104f8f, 18 Jan 2019)
请参阅Johannes Schindelin ( ) 的commit 5bdece0（2018 年 12 月 15 日）。（由Junio C Hamano合并-- --在提交 5104f8f，2019 年 1 月 18 日）dschogitster
gc/repack: release packs when neededOn Windows, files cannot be removed nor renamed if there are still handles held by a process.
To remedy that, we introduced theclose_all_packs()function.Earlier, we made sure that the packs are released just before
git gcis spawned, in case thatgcwants to remove no-longer needed packs.But this developer forgot that
gcitself also needs to let go of packs, e.g. when consolidating all packs via the--aggressiveoption.Likewise,
git repack -dwants to delete obsolete packs and therefore needs to close all pack handles, too.
gc/repack: 需要时发布包在 Windows 上，如果进程仍有句柄，则无法删除或重命名文件。
为了解决这个问题，我们引入了该close_all_packs()功能。早些时候，我们确保包在
git gc生成之前发布，以防gc想要删除不再需要的包。但是这个开发者忘记了
gc自己也需要放开包，例如在通过--aggressive选项整合所有包时。同样，
git repack -d想要删除过时的包，因此也需要关闭所有包句柄。
Update January 2016
2016 年 1 月更新
That should be fixed in Git 2.8 (March 2016) (and see Git 2.19, Q3 2018 below)
这应该在 Git 2.8（2016 年 3 月）中得到修复（参见下面的 Git 2.19，2018 年第三季度）
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)
请参阅Johannes Schindelin ( ) 的commit d562102、commit dcacb1b、commit df617b5、commit 0898c96（2016 年 1 月 13 日）。（由Junio C Hamano合并-- --在提交 3c80940 中，2016 年 1 月 26 日）dschogitster
fetch: release pack files before garbage-collectingBefore 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.
fetch: 在垃圾收集之前释放包文件在 auto-gc'ing 之前，我们需要确保打包文件被释放，以防它们需要重新打包和垃圾收集。
许多
gc --auto在退出之前运行“ ”的代码路径保持包文件映射并将文件描述符保持打开状态，这对无法删除打开的文件的系统不友好。
他们现在在这样做之前关闭包装。
That fixes git-for-widowsissue 500.
这修复了git-for-widows问题 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 2.8 尚未发布）是人为地提高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 755which should also alleviate the issue (commit 2db0641):
git 2.8.4（2016 年 6 月）确实提到了问题 755，这也应该可以缓解这个问题（提交 2db0641）：
Make sure temporary file handles are not inherited by child processes
确保子进程不会继承临时文件句柄
Actually, git-for-windowsissue 500mentioned above is really fixed with Git 2.19, Q3 2018.
See "Git - Unlink of file .idxand .packfailed (The only process owned handle to this file is git.exe)"
实际上，上面提到的git-for-windows问题 500确实在 2018 年第 3 季度的 Git 2.19 中得到了修复。
请参阅“ Git - Unlink of file .idxand .packfailed（该文件的唯一进程拥有句柄是git.exe）”
回答by NeilD
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.
这是一个特定于 Windows 的答案，所以我知道它与您无关......我只是为了将来的搜索者的利益而包含它。
In my case, it was because I was running Git from a non-elevated command line. "Run as Administrator" fixed it for me.
就我而言，这是因为我从非提升的命令行运行 Git。“以管理员身份运行”为我修复了它。
回答by Paul Nikonowicz
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.
对我来说，这是因为 Visual Studio 试图从拉取中重新加载所有更改的文件。让 Visual Studio 刷新，然后运行git gc.
回答by Garrett Smith
On Windows using GitHub for Windows, I got a similar error in the shell when running git gc:
在 Windows 上使用 GitHub for Windows，运行时我在 shell 中遇到了类似的错误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.
我通过关闭 GitHub GUI 解决了它。
回答by Bikey
Closed Visual Studio and Rubymine and didn't get the error again. One of them was the culprit.
关闭 Visual Studio 和 Rubymine 并且没有再次出现错误。其中一个是罪魁祸首。
回答by Arvind Bhardwaj
Try to restart you Apache or other web server as it may have locked some of your files.
尝试重新启动 Apache 或其他 Web 服务器，因为它可能锁定了您的某些文件。
回答by Md. Naushad Alam
Close your IDE then do git pull. It will work.
关闭您的 IDE，然后执行git pull. 它会起作用。
回答by Ruobin Wang
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~~
我也有这个问题，后来发现是UltraEdit挡了路，因为我用UE来组织和编辑我的eclipse工作区~~
Maybe because the UE has a handle on the old version of specific file, Git could not unlink of it.
可能是因为 UE 对旧版本的特定文件有句柄，Git 无法取消它的链接。
After I closed UltraEdit, the problem never happened again.
关闭 UltraEdit 后，问题再也没有发生。
回答by Sebastian Thomas
This was caused in my case by SimpLESS, the LESS compiler. You have to close it in the systray.
在我的情况下，这是由 LESS 编译器 SimpLESS 引起的。您必须在系统托盘中关闭它。
