为什么Windows无法识别WSL符号链接

您是否知道通过Windows Subsystem for Linux（WSL）创建的符号链接（symlinks）无法被Windows识别？

最近几个月我在日常工作中使用WSL时遇到了这个令人沮丧的问题。毫无疑问其他人也注意到了这一点，因此我想记录下来，为寻找答案的人提供参考。

问题示例

我使用WSL2的Ubuntu作为Linux客户端，创建一个文件并在同一目录下创建指向该文件的符号链接（通过ln -s命令）：

1
2

echo "this is a symlink test" > test_symlink.txt
ln -s test_symlink.txt targetfile.txt

在WSL中，我可以轻松读取原始文件（test_symlink.txt）和符号链接（targetfile.txt）。但当我尝试从Windows文件资源管理器打开符号链接时，会出现错误：

从命令行访问targetfile.txt时也会出现同样的错误：

查看目录时，我可以看到目标文件，但其大小为0 KB：

运行dir命令时，可以看到Windows将targetfile.txt识别为NTFS连接点，但无法找到链接指向的位置，就像处理原生Windows符号链接时那样：

技术原因分析

当我在Twitter上询问这种行为时，Bill Demirkapi给出了答案——WSL创建的链接是"LX符号链接"，Windows无法识别。这是因为Linux上的符号链接与Windows上的符号链接实现方式不同：

• 在Windows上，符号链接是一个由内核实现和解释的对象
• 在Linux上，符号链接只是一个带有特殊标志的文件，其内容是指向目标的路径（该路径甚至不需要有效！）

使用FileTest工具，我们可以轻松验证这是一个Linux符号链接，而不是Windows链接。仔细查看甚至可以在文件的DataBuffer中看到目标文件的路径：

FileTest还可以提供关于文件打开失败的更具体错误信息：

事实证明，尝试使用NtCreateFile打开此文件会失败，并出现STATUS_IO_REPARSE_TAG_NOT_HANDLED错误，这意味着Windows将此文件识别为重解析点，但无法识别LX符号链接标签，因此无法跟踪它。

双向兼容性测试

回到WSL，符号链接工作正常——系统可以看到符号链接目标并按预期打开文件：

有趣的是，在Windows上创建的符号链接在WSL中正常工作。我可以在同一目录中创建一个新文件，并使用Windows命令行（cmd.exe）为其创建符号链接：

1
2

echo "this is a test for windows symlink" > test_win_symlink.txt
mklink win_targetfile.txt test_win_symlink.txt

现在Windows将其视为可以识别和跟踪的常规符号链接：

而且Windows符号链接在从WSL内部访问时同样有效：

如果我们使用Windows命令行创建文件连接点并尝试用WSL打开它，也会得到相同的结果：

1
2

echo "this is a test for windows junctions" > test_win_junction.txt
mklink /J junction_targetfile.txt test_win_junction.txt

这是从Windows角度看到的目录：

这是从WSL角度看到的目录：

重要发现

由WSL创建的硬链接在Windows上正常工作，因此此问题仅适用于符号链接。

总结

Windows只能处理使用其标准标签由Windows创建的符号链接，无法处理"LX符号链接"类型的WSL符号链接。然而，WSL可以无问题地处理两种类型的符号链接。

如果您使用Windows和WSL访问相同的文件，值得注意符号链接及其创建方式，以避免遇到我遇到的相同问题。

最后需要指出的是，当Bill Demirkapi测试此行为时，他注意到Windows可以跟踪使用相对路径创建的WSL符号链接，但不能跟踪使用绝对路径创建的符号链接。在我测试的所有系统上，Windows都无法跟踪任何由WSL创建的符号链接。因此，这里仍然存在一些需要调查的谜团。