Windows 上的 Git checkout 和 reset 偶尔会显示随机文件已更改
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1209902/
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
Git checkout and reset on Windows occasionally shows random files have changed
提问by Michael Donohue
Often when I do a checkout of a different branch, or a reset, I will get 'permission denied' errors from windows for one to a dozen files - but the particular files vary from run to run. Here's the output from a test I just did, with GIT_TRACE=1. The trace only added the one line before the error message:
通常，当我对不同的分支进行检出或重置时，我会从 Windows 中收到一到十几个文件的“权限被拒绝”错误 - 但特定文件因运行而异。这是我刚刚进行的测试的输出，GIT_TRACE=1。跟踪只在错误消息之前添加了一行：
$ git checkout master trace: built-in: git 'checkout' 'master' error: git checkout-index: unable to create file dotnet/src/myfile.cs (Permission denied) D dotnet/src/myfile.cs Switched to branch "master"
I'm pretty sure this is some race with a virus scanner or other indexing service on my machine. If the race persisted, I could use sysinternals to see what process has the file handle open. However, it happens very quickly, and I'm not aware of a tool that will show me this conflict. Surprisingly, I haven't found anyone describing similar behavior. How do I make these errors stop, or diagnose the problem further?
我很确定这是我机器上的病毒扫描程序或其他索引服务的竞争。如果竞争持续存在，我可以使用 sysinternals 来查看哪个进程打开了文件句柄。但是，它发生得很快，我不知道有什么工具可以显示这种冲突。令人惊讶的是，我还没有找到任何人描述类似的行为。如何停止这些错误，或进一步诊断问题？
I'm specifically looking to end the file access race by identifying whatever process is doing the simultaneous access.So suggestions for a tool that shows which process has a file locked when an edit is denied would be very helpful. I'm aware of 'unlocker' and similar tools which will show me what process holds a file locked for a period of time. This doesn't work for this issue, because the process keeps the file locked for a very short period. So the tool needs to collect the appropriate data without my intervention, as I'm too slow.
我特别希望通过识别正在执行同时访问的任何进程来结束文件访问竞争。因此，对于显示哪个进程在编辑被拒绝时锁定文件的工具的建议将非常有帮助。我知道“解锁器”和类似的工具会告诉我哪个进程将文件锁定了一段时间。这不适用于此问题，因为该过程会将文件锁定很短的时间。所以这个工具需要在没有我干预的情况下收集适当的数据，因为我太慢了。
采纳答案by Michael Donohue
Disabling UAC Virtualization seems to have fixed the problem.
禁用 UAC 虚拟化似乎解决了这个问题。
回答by mynameistechno
It might be the Windows Search Indexer, which tries do index files as they are created. I ran into this issue with svn checkout and had to exclude that directory from indexing before I could successfully checkout a full project.
它可能是 Windows 搜索索引器，它会在创建文件时尝试对其进行索引。我在使用 svn checkout 时遇到了这个问题，并且必须先将该目录从索引中排除，然后才能成功签出完整的项目。
回答by Andreas Vergison
Not git related!
与 git 无关！
Sysinternals' process monitor reveals that Windows explorer interferes with newly created files, perhaps due to some plugin or what, but it happens.
Sysinternals 的进程监视器显示 Windows 资源管理器干扰了新创建的文件，可能是由于某些插件或其他原因，但它确实发生了。
回答by VonC
You can begin with a:
您可以从以下内容开始：
GIT_TRACE=1
But it may not display much more than your original message regarding this file.
但它可能不会显示比您关于此文件的原始消息更多的信息。
The usual cause is some opened editor which wants to reload the files when changed, and that can conflict with git's file manipulations.
That means: the usual strategy is to repeat your git command afterhaving close as many other applications as you can.
通常的原因是一些打开的编辑器想要在更改时重新加载文件，这可能与 git 的文件操作发生冲突。
这意味着：通常的策略是在关闭尽可能多的其他应用程序后重复您的 git 命令。
I haven't found anyone describing similar behavior
我没有找到任何人描述类似的行为
See this threadfor instance, ot this one, both on Cygwin.
What version of Git are you using (Git on Cygwin, or MSysGit, in a Cygwin session or a Dos session?)
见这个线程的情况下，OT这一块，无论是在Cygwin。
您使用的是哪个版本的 Git（Cygwin 上的 Git 或 MSysGit，在 Cygwin 会话或 Dos 会话中？）
