Windows reserves many possible filenames as reserved 
device names.

Examples are prn.xxx, con.xxx, com1.xxx aux.xxx, etc, 
where xxx can be any extension.  Attempts to 
create/read/write to these files can hang the 
interpreter, but ideally would just throw an OSError.

A partial list of device names is mentioned at:
http://cert.uni-
stuttgart.de/archive/bugtraq/2001/07/msg00086.html

Logged In: YES 
user_id=31435

Did you read the message you referenced with that URL?  I 
agree with it:

"""
Conclusion : applications should not filter out DDNs, 
because they don't fix the problem (basically they make it 
even worse), the OS patch is better because it
fixes *ALL* problems, ...

CONCLUSION : patch your OS, and stop whining about so
called 'bugs' in applications, you will never be able
to completely patch the problem that way.
"""

They're right:  applications cannot fix this; if it's a 
problem for you, then you should download and apply the MS 
OS patches linked to from that article.

Logged In: YES 
user_id=50945

Yes, I read the message (and most of the thread) :)

Apologies for re-opening this bug, but I believe that
something can still be done about it.

I'm using Windows 2K (SP 2), so those patches don't apply to
me.  Those patches merely prevent windows crashing on
certain types of accesses to devices, e.g. the now
well-known C:\NUL\NUL bug.  They don't prevent applications
from hanging when trying to access prn.txt.

Further in the thread starting at that URL, there is some
discussion of possible work-arounds for safely
opening/creating files.  I'm not a Win32 C programmer, so
I've no idea about the technical feasibility of these
solutions in Python.

While I agree that the real problem is in the OS, it seems
to be standard behaviour now for apps to workaround it.  For
example, Textpad (www.textpad.com) will just pop up a dialog
saying "You cannot create this file: this name is reserved
device name" or something similar.  Whether they've just
hard-coded a list of known names or if they're doing
something more advanced I don't know.

This caused a fair bit of confusion for me recently: Python
hung inexplicably in splitting a CSV file of stock data into
seperate files, and one of the Australian Stock Exchange's
stock symbols is "PRN".  The script was extremely simple, so
I eventually realised what was going on, but I dread an
unwary person having to debug this problem in a larger
application.

If you think this sort of ugliness doesn't belong in Python
then feel free to close this bug again, and I won't feel
offended :)

Logged In: YES 
user_id=31435

It's cool to reopen it, but I reclassified it as a feature 
request and will add it to PEP 42.  DDNs can be constructed 
dynamically, so no fixed list of magic names is adequate.  
I don't have the knowledge needed to do what is adequate, 
so the only hope for this is that somebody in the Python 
community who does will notice and volunteer their time to 
fix it.  In the meantime, you might want to install a real 
operating system <wink>.

Logged In: YES 
user_id=1053197

Device filenames can be detected by creating an empty
directory, and testing whether the filename exists in that
directory:

> md c:\empty
> if exist c:\empty\lpt1.txt echo foo
foo
> if exist c:\empty\lpt1.txt\lpt1.txt echo foo
foo
> if exist c:\empty\harmless echo foo
>

But note:
> if exist c:\empty\c:\lpt1.txt echo foo
> if exist c:\empty\:\lpt1.txt echo foo
>

I don't know why filenames containing ':' are treated
differently, but it might be wise to strip any ':' characters
from the path first.

Let's discuss it for 2.6

Cannot reproduce the hang in 2.6.2 (Windows XP) for nul (opening and
reading returns an empty string), prn or coml. Reading from con.xxx
"hangs", but it looks like it's waiting for data and Ctrl+C interrupts it.

It seems that Windows has been "patched"...
open("COM").read() does not hang: it reads from the console until you
hit Ctrl-Z.
Testing on Windows 2000, some device names always succeed, others fail
with IOError when you open them or write to them.

The behavior seems correct to me (except of course this very concept of
special device names), and matches the expectations of the OP.