有一个比较知名的奇异特性：文件系统在解析 UNC(Universal Naming Convention) 路径时，会故意忽略掉最前面添加的盘符字母。
举个例子，假设服务器上有一个共享文件夹，其路径为：\\server\share\directory，如果你在命令提示符下输入下面的命令：
dir P:\\server\share\directory

初看下来，这条指令应该不会执行成功，因为最前面的盘符字母 P 并不存在。但是，结果是这条指令会正常工作，它会忽略掉前面的盘符字母。

为什么会这样设计？

让我们将钟表拨回到 1984 年，那个时候，MS-DOS 3.1 即将发布，此版本增加了对网络的支持。在此之前，一个完整的文件名由三个部分组成：驱动器号、路径和文件名。许多程序代码都依赖于这个规范，并额外做了一些事情：如果用户忘记输入了驱动器号，则它们会”好意地”在前面加上一个驱动器号。

例如，如果你告诉程序，将计算结果保存到服务器上的一个共享文件夹 \\server\share\file.txt, 程序会暗自嘀咕: “哦，亲爱的，这可不好，用户忘记了输入驱动器号！我会把当前的驱动器放在前面，让事情变得更好，”。
结果，它得到了这样一个路径：C:\\server\share\file.txt。而其他程序会提示你：”请输入驱动器号”，而你不能”不，我是想将文件保存到网络上的一个位置，它根本就没有驱动器号，你只需要用我提供的路径就可以了”。
最终，这些程序无论如何都坚持让用户输入一个驱动器号，用户不得不给他们一个。

（相比那些”有用地”将 //server/volume/file 重写为 /server/volume/file 的 Unix 程序，因为它们“知道”连续斜杠会折叠，不知道两个前导斜杠的特殊例外。）

为了保持与提供这种”不需要的帮助”的程序的兼容性，MS-DOS 中网络支持的设计者决定允许奇怪的文件路径，例如上面所说的 C:\\server\share\directory，并忽略最前面的驱动器号。直到今天最新的 Windows 11 操作系统，这个路径解析怪癖仍然存在。

总结

为了保持对现有应用程序的兼容性，Microsoft 的工程师确实下了些功夫。
但历史包袱越来越重，总有一天会扛不动。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《Why is a drive letter permitted in front of UNC paths (sometimes)?》