Closed Stanzilla closed 4 years ago
CON
, PRN
, AUX
, NUL
, COM1
, COM2
, COM3
, COM4
, COM5
, COM6
, COM7
, COM8
, COM9
, LPT1
, LPT2
, LPT3
, LPT4
, LPT5
, LPT6
, LPT7
, LPT8
, and LPT9
. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended..temp
.From a Raymond Chen blogspot (2003):
Why do these magic files exist in every directory? Answer: Because DOS 1.0 didn’t have subdirectories. There was only one directory, which today we would call the root directory, but back then, since there was no such thing as a subdirectory, there was no need to talk about directories in the first place, much less give the only one you have a name. It was just called “the files on your disk”. If magic files didn’t work in subdirectories, then when you tried to, for example, chdir into a subdirectory and then run the assembler, you wouldn’t be able to type “NUL” as the filename and get the magic.
Do these files actually mean anything outside of Win32 command line apps (or more specifically, CMD)? Most of the time they are just "reserved" and doesn't do anything.
And this limitation only exists on Win32 subsystem, you can easily create a file named NUL or CON in WSL, heck you can even open them in a Win32 app using UNC path.
@driver1998 They do not mean anything outside Win32. Within Win32, they're not limited to command line apps.
The reason that NUL doesn't do anything is because it's the null device (equivalent to /dev/null
in *nix parlance). If you try type con
, it echos the console input. If you try type con >prn
, it copies console input to the printer.
The reason that you can access these files using \\.\
is detailed in the aforementioned documentation ("Win32 Device Namespqces"), because it doesn't try to resolve predefine aliases, and the call to \\.\d:\test\nul
is accessing the device driver implementing D:
namespace (which happen to be file system).
The bottom line is that one can always create files with reserved names, but it's not going to play well with the vast majority of Win32 programs. For old-timers, the need of these special handlings arises from compatibility requirements. For newer programs, one can regard the need of using \\.\
syntax as an explicit request to opt of the usual behavior in danger of making a mess.
Sorry - this is a 30+ year old platform limitation with wide-ranging compatibility issues.
Not sure if it's actually in scope since not directly speed related but yes.
When developing cross platform, you have to take extra care to not call files like this.
This is also causing trouble for many cross platform open source tools/communities that have to work around it, see https://github.com/rust-lang/crates.io/pull/695 as example.