Subject: [[email-masked]: CON file name]

From: Richard Stallman <[email-masked]>
Date: Sun, 8 Sep 1996 12:02:24 -0400

Could one of you please look at this?  19.32 is not very different
from the latest release.

------- Start of forwarded message -------
To: [email-masked]
Subject: CON file name
From: Raymond Penners <[email-masked]>
Date: 07 Sep 1996 19:47:38 +0200
Lines: 18

In GNU Emacs 19.32.1 (i386-*-win954.0) of Sat Aug 10 1996 on SPHINX
configured using `configure NT'

In short, Emacs (well, Win 95 actually :) crashes when one tries to
find a file called "con.c".

For example: I have "complete.el" loaded, and when I try to find a
file "console.c" I mostly type:

	C-x C-f con.c M-ret

After that "complete.el" should complete "con.c" to "console.c", but
it first checks if "con.c" exists and crashes. The result is a total
system lockup.

- -- 
Raymond Penners <[email-masked]>
------- End of forwarded message -------

---

From: Andrew Innes <[email-masked]>
Date: Mon, 9 Sep 1996 17:13:53 +0100

>Could one of you please look at this?  19.32 is not very different

I know what the problem is, but I'm not sure how best to avoid it.  (To
some extent, the problem applies to all DOS and NT versions of Emacs.)

The problem is that DOS and NT define several "reserved" file names to
refer to specific devices.  So "CON" (and several variants such as
"CON:" and "CON.xxx") refer the the console handle (equivalent of
/dev/tty on Unix).  Likewise "PRN", "LPT1", "LPT2", ... (and variants as
for CON) refer to various parallel (Centronics) printer ports, and
"AUX", "COM1", "COM2", ... refer to serial ports.  Case doesn't matter;
neither does any directory prefix.

Because of this special handling by the OS, you cannot have a file whose
base name (without extension) is any of these reserved names.  If you
attempt to read or write such a file, it is directed to the specific
device, with all the consequences that implies.  If you try to rename a
file to one containing a reserved name, the operation fails, and so on.

The only way I can think of at the moment to detect these problem names
is by textual examination and comparison with a list of known names that
are reserved.

I guess the only reasonable thing we can do is check for these "illegal"
file names in our shadowing of the open and fopen calls, and force those
calls to fail (see below).  Possibly there is an error code that could
be used or invented to indicate why the open fails.

Does this sound like a reasonable approach?

AndrewI

BTW, the exact problem being hit below is that when Emacs tries to load
con.c, it actually starts reading from the console input handle.  

In 19.30, Emacs on Windows did not have a console handle, so the open
call would simply fail and Emacs would not appear to hang.

In 19.31 and later, Emacs on Windows does have a valid console handle,
so the read blocks waiting for the user to type input - unfortunately
the console window is normally hidden to avoid screen clutter, but even
if it is not hidden the user would probably not think to type ^Z to
terminate the read (there is no indication in the console window that
Emacs is trying to read from it).

---

From: Richard Stallman <[email-masked]>
Date: Tue, 10 Sep 1996 16:10:11 -0400

I am not sure we want to reject these file names for all purposes.
For example, I don't see any harm in write-region to a serial
port or a printer (and I believe that may be used currently).

So I think some of these names should be rejected only for certain uses,
not at the level of `open'.