Title: `open("aux.txt", "w")` fails unexpectedly with FileNotFoundError on Windows
Type: behavior Stage: resolved
Components: Windows Versions: Python 3.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: CarK, SilentGhost, eryksun, paul.moore, steve.dower, steven.daprano, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2019-07-06 17:04 by CarK, last changed 2019-07-06 23:54 by steven.daprano. This issue is now closed.

File name Uploaded Description Edit
bug.png CarK, 2019-07-06 17:04
Messages (5)
msg347436 - (view) Author: Carsten (CarK) Date: 2019-07-06 17:04
I maintain a package which includes a package named "".
I could not install it on my windows machine via pip and others had the same problem also with windows.

I tracked down the problem to ``. On my Windows 7 System with Python 3.7.1 from Anaconda, the following statements all result in a FileNotFoundError:

open("aux", "w")
open("Aux", "w")
open("AUX", "w")
open("", "w")
open("", "wb")
open("aux.txt", "w")

On the other hand the following commands work as expected:

open("aaux", "w")
open("AUX1.txt", "w")
open("", "w")


Can anybody confirm this?

On Linux (I could not reproduce the problem.)
msg347438 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2019-07-06 18:11
aux is one of the reserved filenames on windows:

I don't think Python can do anything about that.
msg347439 - (view) Author: Carsten (CarK) Date: 2019-07-06 19:09
This is a good explanation. Indeed Windows complains if I manually want to create a file "aux.txt" ("This device name is not allowed").

If I want to copy-paste such a file from within a zip-file (Windows Explorer can open zip files) I get an "Unexpected Error".

I think a descriptive error message would be very helpful here. The best mechanism would be if this was generated on system level and then just passed through by to the generated Exception. But just throwing a "FileNotFoundError" without any hint is potentially frustrating.

Suggestion for a better Error message: "Could neither open nor create the desired file. Maybe the filename is not allowed by the underlying os".
msg347440 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-07-06 19:27
DOS device names are reserved in the final component of DOS drive-letter paths. "AUX" (plus an optional colon, spaces, or extension) becomes "\\.\AUX", which is "\??\AUX" in the NT object namespace. By default, "\??\AUX" is a link to "\??\COM1", which, if it exists, is typically a link to "\Device\Serial0". If there's no "COM1", then the kernel returns STATUS_OBJECT_NAME_NOT_FOUND, which the Windows API translates to ERROR_FILE_NOT_FOUND, which the C runtime translates to ENOENT, and finally Python raises FileNotFoundError.

Accessing a DOS device name requires using a device path (prefixed by "\\.\" or "\\?\", and forward slash is okay, e.g. "//./C:/Temp/") or a UNC path (e.g. "//localhost/C$/Temp/"). That said, if we create a file like this, programs that use regular drive-letter paths won't be able to access it. It's better to sanitize reserved DOS device names. This includes "CONIN$" and "CONOUT$", even though Microsoft's documentation overlooks these two.
msg347455 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2019-07-06 23:54
For future reference, please don't post screen shots of plain text, as they make it unnecessarily difficult for blind or visually impaired developers to contribute (and yes, they do exist, I've worked with some, and at least one core developer). Copy the relevant text (including the exception traceback) and paste them into the bug report.

Thank you.
Date User Action Args
2019-07-06 23:54:27steven.dapranosetresolution: third party -> not a bug

messages: + msg347455
nosy: + steven.daprano
2019-07-06 19:27:10eryksunsetnosy: + eryksun
messages: + msg347440
2019-07-06 19:09:55CarKsetmessages: + msg347439
2019-07-06 18:11:51SilentGhostsetstatus: open -> closed

type: behavior
components: + Windows, - IO

nosy: + paul.moore, tim.golden, SilentGhost, zach.ware, steve.dower
messages: + msg347438
resolution: third party
stage: resolved
2019-07-06 17:04:53CarKcreate