3

当我运行 WSL bash shell 时，我可以使用“ln -s”命令来创建符号链接。无论我是使用 NTFS 文件系统还是 WSL 文件系统，符号链接都会按预期创建。具体来说，WSL 文件系统中的链接就像 Linux 符号链接一样工作，而 NTFS 文件系统中的符号链接是 Windows 符号链接，我可以在 WSL 和 Windows 中使用它。

将其与在 WSL 中运行的 Linux 版本的 git 中符号链接的工作方式进行对比。我克隆了一个包含指向 NTFS 文件系统的符号链接的存储库。我不确定链接是什么，但它们绝对不是 Windows 符号链接。

有人可能会说我应该使用 Git for Windows，它会在我克隆 repo 时创建正确的 Windows 符号链接。唯一的问题是我们有编写为每个人都使用的 bash 脚本的工具，这些工具称为 git。它们在 Linux 上运行良好，但在 WSL 中，由于符号链接问题，它们的性能不如预期。我发现我需要在 WSL 中运行所有命令行开发人员工具，以便它们可以相互调用并传递文件路径和环境变量等。所以对于我来说，为 Windows 运行 Git 真的不是一个选择。

有没有办法解决这个问题？如果 WSL bash shell 可以正常运行，那么 Linux 版本的 git 中的一个小改动肯定也可以解决这个问题。这闻起来像是 Windows 和 Linux 之间的某种哲学斗争。或者是否存在早于 Windows 的 Git 的遗产......在这种情况下，肯定有一种方法可以为那些想要使用 Windows 符号链接的人启用对符号链接的新处理。

4

1 回答 1

4

这可能是 Windows 和 Linux 的 Windows 子系统中的一个问题。

模拟的 Linux 环境使用symlink(2)系统调用创建符号链接，就像ln -s命令一样。

这很难支持的原因是因为 Windows 符号链接的功能不如 Unix 符号链接。Unix 符号链接可以指向任何位置，无论该位置的对象如何，并且目标不必存在。另一方面，Windows 符号链接指向文件或目录，但被固定到一种类型。

上游提供的标准 Git 检查是否可以创建指向不存在文件的符号链接。这很重要，因为 Git 不需要在符号链接之前检查目标文件。如果失败，Git 会设置core.symlinks为 false，而写入的是包含符号链接内容的文件。发生此测试时，WSL 无法创建正确类型的符号链接（因为没有目标），因此操作失败。

适用于 Windows 的 Git 可能具有一些功能来解决 Windows 中的符号链接问题。它还有大量补丁，这些补丁不包含在上游发布的版本中，因此不是大多数 Linux 发行版使用的版本。

我应该指出，有一个 Linux 发行版还发布了一个补丁，该补丁允许创建符号链接，只有当它们指向用户（而不是其他任何人）拥有的文件时，它才会以同样的方式破坏事情。

您可以尝试git config core.symlinks true在新的存储库中运行，看看它是否按预期工作；它可能会，也可能不会。如果没有，您可以查看 Git for Windows 维护者是否会将他们正在使用的补丁发送到上游，并且它最终可能会包含在较新版本的 Git 中，因此会包含在较新版本的 Linux 发行版中。然而，由于 Linux 发行版通常提供稳定的版本，这将需要时间，通常在数年左右，除非您下载更新的软件包。

不过，一般来说，您不能指望 Unix 代码在 NTFS 文件系统上充分工作，因为它根本不同，微软甚至记录了这种行为。Microsoft 在添加符号链接时知道（或应该知道）Unix 符号链接的工作原理，并且出于某种原因他们选择了不同的方式。我个人认为这是一个错误，我们现在就在这里。

于 2020-01-17T00:49:28.133 回答