[ python-Feature Requests-481171 ] Hang using files named prn.txt, etc

SourceForge.net noreply at sourceforge.net
Sun May 30 19:21:08 EDT 2004

Feature Requests item #481171, was opened at 2001-11-13 05:43
Message generated for change (Comment added) made by davidhopwood
You can respond by visiting: 

Category: None
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hang using files named prn.txt, etc

Initial Comment:
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:


Comment By: David Hopwood (davidhopwood)
Date: 2004-05-31 00:21

Logged In: YES 

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

> md c:\empty
> if exist c:\empty\lpt1.txt echo foo
> if exist c:\empty\lpt1.txt\lpt1.txt echo 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.


Comment By: Tim Peters (tim_one)
Date: 2001-11-14 05:51

Logged In: YES 

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>.


Comment By: Andrew Bennetts (spiv)
Date: 2001-11-14 01:20

Logged In: YES 

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

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 :)


Comment By: Tim Peters (tim_one)
Date: 2001-11-13 17:41

Logged In: YES 

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.


You can respond by visiting: 

More information about the Python-bugs-list mailing list