windows folder creation surprise from kerneltrap_org

Posted by venkatesh on Monday, October 10, 2005 - 04:53
It was dicovered that nobody can create a folder named as "con" in windows.
This is something pretty cool...and unbelievable...
Note : This should be through & in windows only.
If any one have solution or reason why it happens , let me also know please.

MS-DOS that's the problem!
Comment posted by Anonymous (not verified) on Monday, October 10, 2005 - 12:18
hmm, have you tried to create a folder named "com1" "lpt1" "com2" ... it shouldn't work either!

"con" is a _old_ MS-DOS stuff!

I found how to create a folde
Comment posted by Venkat (not verified) on Wednesday, October 12, 2005 - 14:52
I found how to create a folder or file named CON , LPT1 , COM1 etc...

STEP1: goto command prompt

STEP2: type in prompt e:\> "mkdir \\.\e:\con"

STEP3: verify by typing "dir \\.\e:\con"

STEP4: delete the file or folder "rmdir \\.\e:\con"

it will work like this md Comment posted by yash (not verified) on Wednesday, March 8, 2006 - 21:44
it will work like this
md \\.\\c:\con
dir c:
rd \\.\\c:\con

Please explain
Comment posted by Anonymous (not verified) on Monday, October 17, 2005 - 03:52
Yes, it is working, but I would very thankful to you if you could tell me HOW?
I don't understand anything in it
what \\. means in DOS?
thanks,
sam

UNC
Comment posted by strcmp on Monday, October 17, 2005 - 05:16
This is a UNC path (see http://en.wikipedia.org/wiki/Universal_Naming_Convention). Because these didn't exist under pure DOS, they don't have to be backward compatible (and \\remotehost\drive:\con doesn't make sense anyway, because without having a process on the remote host, there is no current 'console'). It would be a security hazard as well, having the serial and parallel ports accessible for everyone who is allowed to read or write in any single directory.

http://forums.whirlpool.net.a
Comment posted by ruza on Tuesday, October 11, 2005 - 03:10
http://forums.whirlpool.net.au/forum-replies-archive.cfm/409278.html

The following reserved device names cannot be used as the name of a file:

CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.

You must avoid using these names as a file name suffix or file name body, so you have to avoid names such as aux.c, file.aux or NUL.txt.

This actually is a unix-like feature. DOS device drivers are accessible like normal files, i.e. the everything-is-a-file philosophy. CON is the equivalent of /dev/tty, NUL of /dev/null, COM# of /dev/ttyS#, LPT# of /dev/lp# and CLOCK$ corresponds to /dev/rtc (PRN is an alias to LPT1, AUX is COM1). Every character device can be opened this way, block devices (which are assumed to be FAT formatted...) are named A: to Z:, as you will know. Many pseudo character devices (drivers which had to be loaded as drivers but were no character devices, like EMM386, HIMEM.SYS, ..) had forbidden characters like '*' in their device names to be hidden from the user.

The only problem is: DOS 1, which introduced CON, NUL, PRN and AUX had no directories, i.e. no /dev/, so for compatibility with old DOS1-executables (which don't know that they live in a directory) the character devices have to exist in every directory. Don't know why this feature was not limited to FCB (CP/M like) file access, unix like file numbers were introduced together with directories in DOS 2 (actually the MS programmers had Xenix machines on their desks, I heard)..
For a period of time, DOS allowed referencing these files through the directory \DEV, even if \DEV didn't exist. I think they may've intended to deprecate the "available in every directory" behavior, but in the end it got too much inertia behind it.


I'm surprised at the level of comments in this thread. There are other, more appropriate sites for "M$ IS TEH SUX0R" debates.

If you want to learn a few details on why CON, AUX, et al are considered reserved filenames, then continue reading.

Start with the MSDN documentation on file naming. It provides the list of reserved file names. It also explains the "\\?\D:\foo" syntax, with focus on overcoming the MAX_PATH length limitations in the ANSI APIs.

What it doesn't do is tie these ideas together. (It also doesn't mention the "\\.\" prefix, but it basically works like "\\?\".)

In NT-based versions of Windows (NT 3.1-4.0, Win2K, WinXP, Vista, etc) Win32 is implemented as a subsystem on top of the NT OS. One function of this subsystem is to translate filenames and pathnames from the Win32 object namespace to the NT object namespace. It is in this translation layer that the reserved names are handled. (This is also where concepts like "current directory" and "relative paths" are implemented.)

The "\\?\d:\foo" syntax provides a way to bypass the translation mechanism. This is why relative paths are not permitted using this syntax. This is also why you can create files with "Win32 reserved names" using this syntax.

The reserved names "feature" is done for backwards compability with Win16 and DOS applications. Modern versions of Windows and still run 16-bit applications via the included Virtual DOS Machine (VDM). Also, the initial Win32 APIs were, whenever possible, a simple 32-bit "widening" of the 16-bit APIs. I suspect 32-bit support for these reserved names was included to ease the porting of 16-bit apps.

The connection between reserved names and "\\?\d:\foo" may be subtle and not documented very clearly, but there's no magic, no conspiracy, no "MS FORGOT TO REMOVE SOME DOS CODE" mistakes. It may seem unnecessary now, but the industry was very different 16 years ago when Win32 was designed.

I now return you to kerneltrap, and (hopefully) something more relevant to OSS.