为什么Windows无法解析WSL符号链接 - The Trail of Bits博客

Yarden Shafir
2024年2月12日
linux, windows

你是否知道通过Windows Subsystem for Linux (WSL)创建的符号链接(symlinks)无法被Windows系统识别？

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

问题示例

我使用Ubuntu作为WSL2的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文件资源管理器打开符号链接时，会出现错误：

Windows文件资源管理器错误

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

命令行错误

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

目录中大小为0 KB的符号链接

运行dir命令时，可以看到Windows将targetfile.txt识别为NTFS连接点，但无法找到链接指向的位置，这与原生Windows符号链接不同：

Windows无法找到链接指向位置

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

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

FileTest验证为Linux符号链接

FileTest还提供了更具体的文件打开失败错误信息：

FileTest的文件打开失败错误信息

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

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

符号链接在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可以跟踪在Windows上创建的符号链接

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

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角度看到的目录：

从Windows角度看到的目录

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

从WSL角度看到的目录

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

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

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

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