应用程序如何处理 Windows 符号链接？

Question

我认为 Windows 10 中的符号链接的行为类似于 Linux 符号链接，即它们对应用程序是透明的。但是，我对实际行为感到困惑。

例如，我对同一个 CSS 文件进行了软链接和硬链接：

$ mklink softlinked.css Default.css
symbolic link created for softlinked.css <<===>> Default.css

$ mklink /H hardlinked.css Default.css
Hardlink created for hardlinked.css <<===>> Default.css

硬链接的行为可预测（与原始文件无法区分），但我不理解软链接。例如，请参阅：

此外，当 CSS 被 Caret 编辑器使用时，硬链接样式表工作正常：

当软链接被破坏时：

问题是：

1. 符号链接在 Windows 上的实际行为如何？
2. 软链接可以对应用程序透明吗？通过透明，我的意思是应用程序将始终将文件视为位于符号链接路径 ( ...\symlinked.css) 上，并且永远不会解析为原始路径 ( ...\Default.css)。是否有一些 Windows 注册表设置之类的？

Answer 1

符号链接对于使用底层文件系统的应用程序是透明的，例如 CreateFile() 和朋友，除非应用程序做出特别努力来了解它们。

但是，它们对于使用 shell 命名空间的应用程序（例如标准的“打开文件”对话框）并不透明，因为 shell 将符号链接视为快捷方式，甚至可以修改显示的图标。这对微软来说是否是一个明智的决定在现阶段是一个有争议的问题，因为它不会改变。据我所知，它是不可配置的。

在实践中，这通常意味着符号链接对于非 GUI 应用程序和 GUI 应用程序中的内部文件（DLL、内置模板、配置文件等）将是透明的，但对于用户的文档则不然。

因此，您的前两个示例（资源管理器显示文件的方式和 Notepad++ 的行为）是功能而不是错误；不管你喜不喜欢，这就是 Windows 的工作方式。

您的最后一个示例似乎是相关应用程序中的错误（或者充其量是不受欢迎的设计限制）。可能值得联系供应商。

您还应该知道，创建符号链接需要管理权限，并且默认情况下它们根本不适用于网络共享。就我个人而言，鉴于所有这些限制，我从未发现它们非常有用。对于大多数用户任务，我会使用快捷方式，而对于大多数系统管理任务，连接点更可靠。