Created on 2001-11-13 05:43 by spiv, last changed 2009-07-26 08:29 by ezio.melotti. This issue is now closed.
|msg53323 - (view)||Author: Andrew Bennetts (spiv)||Date: 2001-11-13 05:43|
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
|msg53324 - (view)||Author: Tim Peters (tim_one) *||Date: 2001-11-13 17:41|
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.
|msg53325 - (view)||Author: Andrew Bennetts (spiv)||Date: 2001-11-14 01:20|
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 :)
|msg53326 - (view)||Author: Tim Peters (tim_one) *||Date: 2001-11-14 05:51|
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>.
|msg53327 - (view)||Author: David Hopwood (davidhopwood)||Date: 2004-05-30 23:21|
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.
|msg59298 - (view)||Author: Christian Heimes (christian.heimes) *||Date: 2008-01-05 18:16|
Let's discuss it for 2.6
|msg86711 - (view)||Author: Daniel Diniz (ajaksu2)||Date: 2009-04-28 00:01|
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.
|msg90887 - (view)||Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *||Date: 2009-07-24 15:42|
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.
|2009-07-24 15:42:49||amaury.forgeotdarc||set||status: open -> closed|
nosy: + amaury.forgeotdarc
messages: + msg90887
|2009-04-28 00:01:28||ajaksu2||set||priority: normal -> low|
versions: + Python 3.1, Python 2.7, - Python 2.6
nosy: + ajaksu2
messages: + msg86711
stage: test needed
messages: + msg59298
components: + Interpreter Core, Windows, - None
versions: + Python 2.6