在Windows WSL中运行并在NTFS文件系统上操作时，Linux git为什么不创建适当的Windows符号链接？

Question

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

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

有什么办法可以解决这个问题吗？如果WSL bash shell能够正常工作，那么git的Linux版本中的一个小改动肯定也可以解决这个问题。这有点Windows和Linux之间的哲学斗争的味道。或者这是在Git for Windows之前遗留下来的...在这种情况下，肯定有一种方法为那些想要使用Windows符号链接的人启用符号链接的新处理方式。

Answer 1

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

仿真Linux环境使用symlink(2)系统调用创建符号链接，这与ln-s命令的操作非常相似。

之所以难以支持，是因为Windows符号链接的功能不如Unix符号链接。Unix符号链接可以指向任何位置，与该位置的对象无关，目标不需要存在。另一方面，Windows符号链接指向文件或目录，但固定在一种类型上。

您可以尝试在一个新的存储库中运行git config core.symlinks true，看看这是否能如您所期望的那样工作；可能会，也可能不会。如果不是，您可以查看Git for Windows maintainer是否会向上游发送他们正在使用的补丁，它最终可能包含在较新版本的Git中，从而包含在较新版本的Linux发行版中。然而，由于Linux发行版通常提供稳定的版本，这将需要时间，通常是年的数量级，除非您下拉一个较新的包。

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