Git init:致命:无法将'core.filemode'设置为'false' [英] Git init: fatal: could not set 'core.filemode' to 'false'

问题描述

使用 Team City 从 Git 存储库中签出.(如果重要的话，Gitlabs)

Using Team City to check out from a Git Repo. (Gitlabs if it matters)

从空构建目录开始.得到这个错误:

Start with Empty build directory. Get this error:

致命:无法将core.filemode"设置为false"

fatal: could not set 'core.filemode' to 'false'

(在 Windows 机器上运行，如果重要的话)

(Running on a Windows machine, if that matters)

Team City 的运行用户已更改为管理员以防万一.

The user that Team City is running on was changed to an Admin just in case.

此命令退出时，.Git 目录不是有效的 Repo.

The .Git directory is not a valid Repo when this command exits.

擦除整个工作"目录没有帮助.

Wiping the entire 'work' directory doesn't help.

它随机地来来去去……

还有这个:git config --global --replace-all core.fileMode false

AND this: git config --global --replace-all core.fileMode false

没有任何用处 - 使用或不使用 --replace-all，并以管理员或其他用户身份运行(如果将false"更改为true"，如果将其更改为falseCD"，则会收到相同的错误它将错误更改为无效值 - 很明显，它正在更改它.

Does nothing useful - with or without the --replace-all, and run as admin, or another user (if you change 'false' to 'true' you get the same error, if you change it to 'falseCD' it changes the error to that being an invalid value - so clearly, it is changing it.

有人有什么想法吗?

推荐答案

Traderhunt Games 将此追溯到某些防病毒软件，这是有道理的.原因与 Git 用于更新配置条目的过程有关.

Traderhunt Games traced this to some antivirus software, which makes sense. The reason has to do with the process Git uses to update a configuration entry.

当 git config 运行并被告知更改一个或多个配置 key = value 字段时，例如更改 core.filemode to false，它的实现方式是使用三步流程:

When git config runs and is told to change one or more configuration key = value field(s), such as changing core.filemode to false, the way it implements this is to use a three-step process:

1. 使用创建文件的 OS 服务调用创建一个新的空文件 (.git/config.lock)，如果文件已存在则失败.如果此步骤失败，则表明另一个 git config(或等效)命令 已经在运行，我们必须等待它完成，然后再执行我们自己的 git配置.

1. Create a new, empty file (.git/config.lock), using the OS service call that creates a file, or fails if the file already exists. If this step fails, that indicates that another git config (or equivalent) command is already running and we must wait for it to finish before we do our own git config.

读取现有的配置文件，一次一个key = value条目.如果 key 是我们关心的那个，就写 new key = value 值，否则复制现有的 key = value.

Read the existing configuration file, one key = value entry at a time. If the key is the one that we care about, write the new key = value value, otherwise copy the existing key = value.

这里有一些花哨的键是允许重复的，而不是只应该出现一次的键；有关详细信息，请参阅 git config 的 --replace-all 和 --unset-all 选项.请注意，git config 本身对大多数键值对几乎一无所知，并且您可以发明自己的键/值对，只要您选择 Git 目前不使用且不会使用的键将来使用.(你如何弄清楚 Git 将在 2043 年使用和不使用什么，我不知道.:-))主要的例外是一些 core.* 值，它们git config 可以理解，其他几个Git命令可以自行设置.

There's some fanciness here with keys that are allowed to repeat, vs keys that should only occur once; see the --replace-all and --unset-all options to git config for details. Note that git config itself knows little to nothing about most key and value pairs, and you can invent your own key/value pairs as long as you pick keys that Git is not using today and won't be using in the future. (How you figure out what Git will and won't use in, say, the year 2043, I have no idea. :-) ) The main exceptions are some of the core.* values, which git config does understand, and several other Git commands may set on their own.

(请注意，--unset 的处理方式与替换非常相似.就像非 all 替换一样，它只会取消设置 first匹配 key = value 对.取消设置是通过简单地不写给定的键来实现的，而不是写一个替换 key = value.因为 >git config 只是逐行处理文件，这很容易做到.此外，如果您的 key = value 是全新的，Git 通过阅读所有行，注意到它没有替换任何现有的 key，因此 add 一个新的 key = value 行.这有点复杂事实上，键是逐节列出的，但逻辑本身很简单.)

(Note that --unset is handled much the same as replacing. Like a non-all replace, it only unsets the first matching key = value pair. Unsetting is implemented by simply not writing the given key, instead of writing a replacement key = value. Since git config is simply working through the file line-by-line, that's easy to do. Also, if your key = value is totally new, Git handles this by reading through all the lines, noticing that it did not replace any existing key, and hence adding a new key = value line. This is complicated a bit by the fact that the keys are listed section-by-section, but the logic itself is simple enough.)

最后，阅读了整个现有配置并完全写出新配置(使用 fflush 和 fsync 和 fclose等等)，git config 调用 OS 服务来rename 一个文件，以便将 .git/config.lock 重命名为.git/config.这是在这种特殊情况下流程失败的地方.

Finally, having read through the entire existing configuration and completely written out the new one (using fflush and fsync and fclose and so on as needed), git config invokes the OS service to rename a file, in order to rename .git/config.lock to .git/config. This is where the process is failing in this particular case.

重命名，如果成功，则具有使新配置生效和删除锁定文件的效果，所有这些都作为一个原子操作:任何其他 Git 命令看到完整的旧配置，来自原始 .git/config 文件，或完整的新配置，来自在构造期间称为 .git/config 的新 .git/config 文件.lock.

The rename, if it succeeds, has the effect of putting the new configuration into effect and removing the lock file, all as one atomic operation: any other Git command sees either the complete old configuration, from the original .git/config file, or the complete new configuration, from the new .git/config file that was known during construction as .git/config.lock.

StackOverflow 的另一个问题是:我们能否在 Windows 中删除打开的文件? accepted answer 包含以下声明:无法打开启用完全共享(包括删除)的文件的防病毒产品存在问题. 如果是这种情况——也就是说，如果这个特定的 AV 软件无法使用允许删除"标志打开，并且如果这样的软件有错误，那么这个特定的 AV 软件就是问题并且有错误.

Another StackOverflow question asks: Will we ever be able to delete an open file in Windows? The accepted answer includes this statement: An anti virus product that does not open files with full sharing (including deletion) enabled is buggy. If that's the case—that is, if this particular AV software fails to open with the "allow delete" flag, and if such software is buggy, then this particular AV software is the problem and is buggy.

这篇关于Git init:致命:无法将'core.filemode'设置为'false'的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！