Windows是否识别Linux的符号链接？

我只是想知道Windows系统如何处理符号链接。我最好的猜测是它不会识别它们，但是我不确定。

另外，面对Mac，Mac会做什么？

在谈论非本地磁盘时，取决于Windows版本和服务器端的配置。

从Windows Vista开始，Windows确实有了符号链接的概念，但是语义有所不同。但是这里更重要的问题应该是路径名，它遵循不同的语法。对于初学者：单根目录树在unixoid端，几个驱动器号作为根在Windows端。

在unixoid方面，符号链接只是带有特殊标志的文本文件。在Windows方面，基本机制称为重新解析点。这告诉对象管理器将其传递给特定的已注册过滤器（其元数据存储在重新解析点中）。Windows 2000已经引入了一种称为重合点的重解析点（大约但不是完全的目录符号链接）。借助Vista，他们在文件和目录（以及远程驱动器）上都引入了符号链接。并且在某种程度上也支持远程驱动器上的符号链接。

要点是文件系统驱动程序（在本地运行时）是否会对Windows看到的路径进行任何调整。在这种情况下，它将对某些本地/相对符号链接起作用。对于绝对路径作为目标，将很难且不可能推断出含义。对于远程符号链接（指向“网络共享”）也是如此。

至于Mac方面，我一无所知，作为一个单独的问题可能有意义。但是只要服务器端传达这是一个符号链接的信息，我就看不到任何问题，因为它们都遵循SUS语义（与Windows不同）。

考虑Linux的侧面安装点：

/dev/sda1 /
/dev/sda2 /home
/dev/sda3 /var

现在考虑/home/paul/fstab指向的符号链接/etc/fstab。它们位于两个不同的卷上，Windows –如果能够通过文件系统驱动程序查看它们（确实起作用！），则无法区分它们的/etc/fstab描述方式。因此\paul\fstab，即使文件夹已翻译，Windows也会在Windows下看到的链接指向，该链接在\etc\fstab上不存在/dev/sda2。而且，如果该符号链接指向相对路径，则../../etc/fstab一切都不会改变。

要点：因此，尽管可以想到可以在某些极端情况下使用该方法，但是在篱笆的两侧语义和语法不同的事实使您不太可能找到可行的通用方法。

对于Windows方面，0xC0000022L的答案是彻底的。Mac可以识别Linux的符号链接。但是Linux无法识别在Mac的Finder中创建的别名（使用ln -s创建的符号链接可以正常工作）。