Git init：致命：无法将'core.filemode'设置为'false'答案

【问题标题】：Git init: fatal: could not set 'core.filemode' to 'false'Git init：致命：无法将'core.filemode'设置为'false'
【发布时间】：2022-02-02 07:25:22
【问题描述】：

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

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

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

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

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

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

擦除整个“工作”目录没有帮助。

它随机地来来去去……

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

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

有人有什么想法吗？

【问题讨论】：

很明显，Git 正在尝试更改配置设置，但失败了。不清楚的是为什么。 Git 通过创建.git/config.lock 来更新.git/config，在那里写入新配置，然后将完成的.git/config.lock 重命名为.git/config。如果其中一个步骤失败（无法创建 .lock、无法写入 .lock 文件、无法将 .lock 文件重命名到位），则会出现上述错误。找出这三种情况中的哪一种以及为什么。
它只是创建了目录（之前没有 .git），所以如果有一个 config.lock 文件，那么这个进程只是将它创建为“git init”命令的一部分。它在目录中创建了许多其他文件，包括“config”文件，它对正在运行 git 的进程的机器具有完全的管理员访问权限。我相信，这已经排除了所有这三个......
因此，解决此问题的一种方法是告诉 git 在配置文件一开始就不要更新它。我在尝试将值设置为 false 和在另一个项目上都看到错误 'true' 。我尝试使用 --system 而不是 --global 并没有帮助。（甚至不确定） - 哦，没有 config.lock 文件。如果它不能重命名文件，它应该发出一个错误说明（怀疑它确实如此），如果它不能创建它，它应该发出一个错误说明（怀疑它确实如此）。我宁愿期待它与任何看似显而易见的事情无关:-(
我不“做”Windows，但据我了解，Windows 具有强制文件锁定功能，如果某个进程打开文件而另一个进程尝试操作该文件，则第二个进程的尝试会失败.也许一些挥之不去的后台进程（TeamCity 的一部分？）正在打开一些东西，阻止 Git 在这里完成任何事情，尽管有管理员权限。
另一个线索 - 它似乎与由于某种原因无法更新文件'config'有关（它只是创建它），因为从 --system 级别删除了 core.filemode，现在它失败：致命：无法将'core.bare'设置为'false'

标签： git teamcity gitlab

【解决方案1】：

在我的情况下，使用“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'

执行“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.

【讨论】：

那么看来是权限问题了。我们如何通过正确的chmoding 来解决它？
我想也为我工作过。在我的情况下，我在 Windows 10 中的 WSL 中克隆到 Windows 目录的符号链接（“/mnt/c/mydir/...”）。
我在想：“伙计，我不需要阅读所有这些答案......”。然后我发现了这个美丽的答案。非常感谢！

【解决方案2】：

我讨厌成为那种人，但我通过重新启动 Windows 解决了这个问题。

【讨论】：

我也通过重启windows解决了
谢谢你的笑声。顺便说一句，你也解决了问题

【解决方案3】：

Traderhunt Games traced this to some antivirus software，这是有道理的。原因与 Git 用于更新配置条目的过程有关。

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

使用创建文件的 OS 服务调用创建一个新的空文件 (.git/config.lock)，如果文件已存在则失败。如果此步骤失败，则表明另一个git config（或等效）命令已经在运行，我们必须等待它完成，然后再执行我们自己的git config。
李>
读取现有配置文件，一次一个key = value 条目。如果键是我们关心的那个，写 new key = value 值，否则复制现有的key = value。

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

（注意--unset 的处理方式与替换非常相似。与非all 替换一样，它只会取消设置匹配key = value 对的first。取消设置只需通过不写给定的密钥，而不是写一个替换key = value。由于git config只是逐行处理文件，这很容易做到。另外，如果你的key = value是全新的，Git 通过阅读所有行来处理这个问题，注意到它没有替换任何现有的key，因此添加一个新的key = value 行。事实上这有点复杂键是逐节列出的，但逻辑本身很简单。）
最后，在阅读了整个现有配置并完全写出新配置后（根据需要使用fflush 和fsync 和fclose 等），git config 调用操作系统服务以重命名一个文件，以便将 .git/config.lock 重命名为 .git/config。 这是在这种特殊情况下流程失败的地方。

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

另一个 StackOverflow 问题问：Will we ever be able to delete an open file in Windows? accepted answer 包含以下声明：无法打开启用完全共享（包括删除）的文件的防病毒产品有问题。 如果是这种情况——也就是说，如果这个特定的 AV 软件无法打开并带有“允许删除”标志，并且如果该软件有错误，那么这个特定的 AV 软件就是问题并且有错误。

【讨论】：

【解决方案4】：

对我来说，只是在 /etc/nsswitch.conf

中注释掉两行

我注释掉的行是：

group: files # db
db_enum: cache builtin

然后关闭并重新打开 cygwin

【讨论】：

【解决方案5】：

在通过 samba 挂载到 linux 的 Windows 共享驱动器上运行 git init 时出现此错误。我使用 sudo 进行 init，然后 chown 回原来的用户，从那以后一切都很好：

sudo git init # no error
sudo chown user:user .git -R # drop sudo requirement
git add file1 # works normally
git commit -am bla # works normally

【讨论】：