Windows保留关键字文件夹创建不符文档：Java创建风险及跨系统疑问

一、现代Windows创建“非法”保留名的风险 #

• 跨版本兼容性问题：老版本Windows（如Win7/XP）完全无法识别这类文件夹，会导致文件无法访问、程序崩溃，甚至数据丢失。
• 系统工具异常：cmd、PowerShell等原生工具会将这些名称识别为系统设备，比如删除CON文件夹时，cmd会误操作成访问控制台，导致命令无响应或执行错误。
• 程序逻辑混乱：依赖标准文件API的程序可能出现异常，比如读取CON文件夹时，实际读取的是控制台输入而非文件内容，导致数据错误。
• 删除与维护困难：部分此类文件夹无法通过常规方式删除，必须使用特殊命令（如rmdir \\.\C:\Testing\CON），增加维护成本。

二、微软文档与实际结果不符的原因 #

• 规则放宽：现代Windows（Win10及以后）对保留名的限制有所放松：
  • 带扩展名的保留名（如CON.txt）会被识别为普通文件，而非设备，因此可以创建。
  • COM0-COM9中，早期DOS仅保留COM1-COM4，现代Windows中未被实际占用的编号（如COM0）允许创建文件夹。
• API差异：Java的File/Path类调用Windows底层API，而底层API对非核心保留名（如纯NUL以外的名称）的检查已放宽，允许创建。
• 文档更新滞后：官方文档仍沿用早期DOS/Windows的规则，未及时同步现代系统的实际行为。

三、未添加防护的隐性Bug #

• 文件操作失效：程序遍历文件夹时，遇到CON会误读取控制台输入，导致遍历中断或获取错误数据。
• 数据丢失：写入NUL文件夹时，数据会被直接丢弃，但程序可能误以为写入成功，引发数据丢失问题。
• 跨环境崩溃：在Win11正常运行的程序，放到老版本Windows上可能直接崩溃或无法访问文件。
• 调试困难：这类Bug不会抛出明显异常，仅表现为数据异常、程序无响应等，定位难度大。

四、Unix/macOS的保留名情况 #

• Unix/Linux：没有DOS风格的保留文件名，/dev/null、/dev/tty等是/dev目录下的特殊设备文件，普通目录下可以创建名为null、tty的文件或文件夹，不会被识别为设备。
• macOS：基于Unix内核，行为与Unix一致，普通目录下允许使用CON、NUL等名称，无Windows式的保留名限制。

附测试代码 #

@Test
public void test() throws IOException {
    Path dirTest = Paths.get("C:\\Testing");
    File fNul = dirTest.resolve("NUL").toFile();
    assertTrue(fNul.mkdir());
    assertFalse(fNul.exists()); //The only one impossible to create

    String[] vKeywords = {"CON", "PRN", "AUX" };
    for (String s : vKeywords) {
        File f = dirTest.resolve(s).toFile();
        assertTrue(f.mkdir());
        assertTrue(f.exists() || s.equals("NUL"));
    }
    String[] vPrefixes = {"COM", "LPT" };
    for (String s : vPrefixes) {
        for (int i = 0; i < 10; i++) { // 0-9 suffix
            File f = dirTest.resolve(s + i).toFile();
            assertTrue(f.mkdir());
            assertTrue(f.exists());
        }
    }
}

内容的提问来源于stack exchange，提问作者MasterHD