Git init：致命：无法将“core.filemode”设置为“false”

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

提问by Traderhut Games

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

使用 Team City 从 Git 存储库中签出。（如果重要的话，Gitlabs）

Start with Empty build directory. Get this error:

从空构建目录开始。得到这个错误：

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

致命：无法将“core.filemode”设置为“false”

(Running on a Windows machine, if that matters)

（如果重要的话，在 Windows 机器上运行）

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

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

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

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

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

擦除整个“工作”目录无济于事。

It randomly comes and goes...

它随机来来去去......

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

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

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.

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

Anyone got any ideas?

有人有任何想法吗？

采纳答案by torek

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.

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

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

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

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 runningand we must wait for it to finish before we do our own git config.

2. Read the existing configuration file, one key = valueentry at a time. If the key is the one that we care about, write the newkey = valuevalue, otherwise copy the existing key = value.

   There's some fanciness here with keys that are allowed to repeat, vs keys that should only occur once; see the --replace-alland --unset-alloptions to git configfor details. Note that git configitself 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 configdoesunderstand, and several other Git commands may set on their own.

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

3. Finally, having read through the entire existing configuration and completely written out the new one (using fflushand fsyncand fcloseand so on as needed), git configinvokes the OS service to renamea file, in order to rename .git/config.lockto .git/config. This is where the process is failing in this particular case.

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

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

   这里有一些奇特的键允许重复，而键应该只出现一次；有关详细信息，请参阅--replace-all和--unset-all选项git config。请注意，git config它本身对大多数键值对知之甚少，只要您选择 Git 现在不使用且将来不会使用的键，您就可以发明自己的键/值对。（你如何确定 Git 在 2043 年将使用什么和不使用什么，我不知道。:-)）主要的例外是一些确实理解的core.*值，并且可能会设置其他几个 Git 命令他们自己。git config

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

3. 最后，通读整个现有配置并完全写出新配置（根据需要使用fflush和fsync等fclose），git config调用操作系统服务重命名文件，以便重命名.git/config.lock为.git/config. 在这种特殊情况下，这是流程失败的地方。

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

重命名，如果成功，就会使新配置生效并删除锁定文件，所有这些都是一个原子操作：任何其他 Git 命令都会看到完整的旧配置，来自原始.git/config文件，或完整的新配置，来自.git/config在构建过程中称为.git/config.lock.

Another StackOverflow question asks: Will we ever be able to delete an open file in Windows?The accepted answerincludes 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.

另一个 StackOverflow 问题问：我们能否在 Windows 中删除打开的文件？该接受的答案包含着这样一句话：防病毒产品，不具有完全共享（包括删除）未打开的文件启用是马车。如果是这种情况——也就是说，如果这个特定的 AV 软件无法打开并带有“允许删除”标志，并且如果此类软件有问题，那么这个特定的 AV 软件就是问题所在并且有问题。

回答by linuxstack

In my case using "sudo" worked for me. For example:

在我的情况下，使用“sudo”对我有用。例如：

asif@asif-vm:/mnt/prog/protobuf_tut$ git clone https://github.com/protocolbuffers/protobuf.git
Cloning into 'protobuf'...
error: chmod on /mnt/prog/protobuf_tut/protobuf/.git/config.lock failed: Operation not permitted
fatal: could not set 'core.filemode' to 'false'

After doing a "sudo" I could get it working:

做了一个“sudo”后，我可以让它工作：

asif@asif-vm:/mnt/prog/protobuf_tut$ sudo git clone https://github.com/protocolbuffers/protobuf.git
Cloning into 'protobuf'...
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 66782 (delta 0), reused 0 (delta 0), pack-reused 66777
Receiving objects: 100% (66782/66782), 55.83 MiB | 2.04 MiB/s, done.
Resolving deltas: 100% (45472/45472), done.
Checking out files: 100% (2221/2221), done.