第 1154 期：为什么 Windows 11 至今仍不允许将文件命名为 CON

在 Windows 11 中，您可以给文件起一个长达 200 个字符、充满空格和表情符号的名称，但请千万别尝试将文件或文件夹命名为“CON”，因为文件资源管理器会直接拒绝。CON、PRN、AUX、NUL 以及 COM1 至 COM9 和 LPT1 至 LPT9 都是操作系统保留的。微软资深工程师 Raymond Chen 指出，这些名称的由来源于 DOS 1.0——那个连文件夹都没有的操作系统！

我在运行 Windows 11 26H2 的电脑上试了一下，发现这个 1981 年沿袭至今的规则依然有效，不过我们发现，其中一部分行为已不再完全符合微软官方文档的描述。

在 Windows 11 中，CON、PRN、AUX 和 NUL 都是设备，而不是文件名

每个保留名称都对应一个设备，而 NUL 是我最喜欢的：一个会吞噬您发送给它的任何内容的 “黑洞”。

微软的文件命名文档仍然告知开发者：“请勿将以下保留名称用作文件名”，这些规则同样适用于文件夹，因为 Windows 将文件夹视为一种特殊类型的文件。

添加扩展名本不应该有任何作用（剧透：在某些情况下确实会起作用）。据微软称，“NUL.txt 和 NUL.tar.gz 都等同于 NUL”。就连上标数字也不例外，因为 Windows 会将 ¹、² 和 ³ 视为数字，所以 COM¹ 和 LPT³ 在 “每个目录” 中都被保留。

从架构上看，COM1 是 Windows 内核中串行端口的一个链接，微软将其称为 MS-DOS 设备名，因此输入 COM1 实际上是访问该端口，而不是某个文件。

Raymond Chen 解释了为何 DOS 1.0 的一条规则在 Windows 11 中仍然有效

故事始于 CP/M——MS-DOS曾试图与其保持兼容的操作系统。在 CP/M 中，设备名称总是带有冒号，例如 CON:。而 MS-DOS 则将冒号设为可选，OS/2 博物馆的 米哈尔·内卡塞克 称其为 “致命缺陷”，因为像 CON 这样简单的名称无法让 DOS 判断用户指的是文件还是控制台。

在 2003 年发表于其 “Old New Thing” 博客的一篇文章中，Raymond Chen 解释道：“DOS 1.0 不支持子目录、小写字母，也不允许文件名超过 8.3 格式”，这也正是为何 Windows 11 中最古老的系统文件至今仍沿用 DOS 时代的命名规则的奇特原因。

那时，如果汇编器询问输出应保存到何处，而您又想要一份打印输出，“只需将文件名设为 ‘PRN’ 即可”。输入 “NUL” 则会丢弃输出，而输入 “CON” 则会将其显示在屏幕上。

由于磁盘上只有一个目录，这些特殊名称也只能在此目录下生效。等到 1983 年 DOS 2.0 引入了文件夹功能后，Raymond Chen 提到：如果这些特殊名称在文件夹内不起作用，您就无法切换到某个文件夹、运行汇编器，再输入 “NUL” 来丢弃输出。因此，微软决定，让这些特殊名称在每一个文件夹中都能正常使用，而这一决策，也导致如今您的 “文档” 文件夹中无法创建名为 “PRN” 的文件。

那么，为什么微软在四十多年里一直没有解决这个问题呢？“因为大家仍然依赖它们，”Raymond Chen 写道。批处理文件通过将输出重定向到 >NUL 来隐藏输出，脚本则用 “if exist directoryname\nul” 来检查某个文件夹是否存在，而一些老旧的使用指南还会教您用 “copy CON” 来创建文件。

更巧的是，如果取消这条规则，所有将输出重定向到 NUL 的脚本都会开始真正地写入文件。

有趣的是，这条规则曾经导致整台电脑崩溃。Windows 95 和 98 对只包含一个设备名的路径能够正常处理，但遇到像 C:\con\con 这样的双设备名路径时就会出错。微软在 2000 年 3 月发布的 MS00-017 公告中也承认，这种情况 “通常会导致系统崩溃”。

我在 Windows 11 26H2 上测试了 DOS 时代的命名规则，结果 NUL.txt 竟然 “蒙混过关” 了

在我运行 Windows 11 26H2 的电脑上，将一个新创建的文件夹重命名为 CON 时，系统提示 “指定的设备名无效”，而 PRN、AUX、NUL 和 COM1 也被拒绝。

然而，NUL.txt 却顺利通过了，CON.txt 也是如此，尽管微软的官方文档仍然明确指出 NUL.txt 就是 NUL。

那么，如果微软没有及时更新，早在2022年，那些深入研究 Python Windows 支持的开发者就发现，Windows 11 在处理文件路径时，已不再将带有扩展名的设备名称视为特殊处理对象。

不幸的是，这类文件的行为往往很奇怪。一位用户在微软问答社区中发现，PowerShell能够列出 NUL.txt，却无法打开或删除它。而一位社区版主回复称，“结果可能不可预测”。或许正因如此，微软才坚持认为 NUL.txt 和 CON.txt 对扩展名并不敏感。

为了增添一点趣味，您可以在命令提示符中体验一下当年 DOS 的 “魔法”。运行 `echo hello > CON` 会在屏幕上直接输出 “hello”，而不会创建文件。同样，`echo test > COM¹` 也会失败，正如微软的官方文档所描述的那样。

不过，在批评 Windows 之前，您需要知道：2024 年，Linux 的维护者将一个图形驱动程序的文件名从 `aux.c` 改为 `auxch.c`，因为原来的文件名会阻止用户在 Windows 上克隆 Linux 内核。

现在您可以批评 Windows 了——毕竟 Linux 为了 Windows 而修改了自己的代码，而 Windows 却不愿放弃一条制定于 1981 年、几十年来无人触及的规则。

不过，Windows 11 确实对这一规则做了一点松动，允许 NUL.txt 通过。但 CON 仍然被视为设备名，而非文件名。就像 Windows 95 的堆管理器至今仍随 Windows 11 一起发布一样，这又是一个微软无法移除的遗留问题，否则就会破坏某些人编写了三十年的批处理脚本。

另外值得一提的是，如果您是一位高效能人士，拓扑梅尔智慧办公平台最近也更新到了最新的 6.0 版本，带来了诸如文件管理，个人工作台，文件秒搜，远程协助，音视频通话等功能，可以帮助您进一步提升日常工作效率。

您在 Windows 11 中还发现了哪些上古遗迹呢？