Why can't "con" be used as the file name under Windows system?

The prohibition against using "con" as a file or folder name in the Windows operating system is a direct legacy artifact from its MS-DOS heritage, specifically tied to reserved device names. In DOS, and subsequently in Windows, certain names are reserved for logical devices to allow programs to communicate with hardware and system resources through the file system API. "CON" specifically refers to the console, which handles input from the keyboard and output to the screen. When a program attempts to open a file named "con," the system intercepts this request and redirects it to the console device driver rather than the file system. This design was a clever abstraction for its time, treating devices as files, but it creates a permanent namespace conflict that prevents user files from claiming these reserved identifiers. The restriction is enforced at the kernel level within the Windows object manager, making it a fundamental, non-configurable rule of the NTFS and FAT file systems as accessed through the Windows API.

The mechanism behind this restriction is deeply embedded in the Windows subsystem. The reserved names include not only "CON" but also others like "PRN" (printer), "LPT1" through "LPT9" (parallel ports), "COM1" through "COM9" (serial ports), and "NUL" (the null device), among others. These are treated as special files within the device namespace (typically accessed via paths like `\\.\CON`). When any file creation request is processed, the system checks the name against this reserved list, irrespective of file extension or case (e.g., "con," "CON," or "Con" are all blocked). This check occurs before any disk access, so even attempting to create such a file via command-line commands like `echo > con` or through File Explorer will fail with an error indicating the name is invalid or reserved. The restriction applies to the final file or folder name component; while a path like `C:\temp\con` is forbidden, a file named `con.txt` is equally blocked because the base name "con" is reserved.

The implications of this legacy constraint are multifaceted. For users and developers, it represents a persistent, low-level incompatibility with other operating systems like Linux or macOS, where such names are generally permitted, potentially causing issues in cross-platform file synchronization or software deployment. It also serves as a minor security and stability feature, albeit an archaic one, by preventing applications from inadvertently hijacking or interfering with device communication channels. However, the primary consequence is one of backward compatibility. A vast amount of legacy software, including critical system utilities and APIs, may rely on the assumption that attempting to open "CON" will access the console. Changing this behavior could break untold numbers of applications, a risk Microsoft has consistently deemed unacceptable. While technically possible to bypass the restriction using low-level NT path prefixes like `\\?\` in some contexts, or by using the POSIX subsystem in Windows Server, these are not standard user solutions and underscore the rule's systemic nature.

Ultimately, the inability to use "con" as a filename is not a bug but a defined, if anachronistic, specification of the Windows platform. It exemplifies how deeply historical design decisions, particularly those concerning system abstraction and resource management, can become frozen into a modern operating system's architecture. The cost of removing this restriction—potentially breaking decades of software that depends on the reserved device namespace—far outweighs the negligible benefit of allowing a few additional filenames. Therefore, this constraint persists as a fixed boundary in the Windows file naming policy, a direct bridge to its command-line past that is maintained for absolute system consistency and compatibility.