Eryk Sun <eryk...@gmail.com> added the comment:
> Perhaps Windows builds can check for reserved file names and give a
> more descriptive error message in the event of IO error?
An operation on a reserved DOS device name can also succeed with unexpected
results. For example, a script may unintentionally write to the active console
screen buffer, "conout$":
>>> open('C:/conout$::. .::.dat', 'w').write('spam\n')
spam
5
There's also the issue of normalization that removes trailing spaces and dots
from the final path component. All paths get normalized, except for device
paths that begin with exactly "\\?\" (i.e. extended paths) in a create or open
context. For example, say a script creates a file with the reserved name "spam.
. .":
>>> open(r'\\?\C:\Temp\spam. . .', 'w').close()
Then later, it generically uses os.walk('C:/Temp'), without the "\\?\" prefix,
and tries to remove the file:
>>> os.remove('C:/Temp/spam. . .')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
FileNotFoundError: [WinError 2] The system cannot find the file specified:
'C:/Temp/spam. . .'
Without an extended path, "spam. . ." gets normalized as "spam". The script
would need to use os.walk(r'\\?\C:\Temp'). Should we special case this error as
well to suggest using an extended path?
> Eryksun also mentions two reserved names which Microsoft apparently
> does not document: "CONIN$" and "CONOUT$".
The system's behavior with these two names depends on the Windows version. In
Windows 7 and earlier, "CONIN$" and "CONOUT$" are special cased by CreateFileW,
and only when it's just the bare names (case insensitive) without trailing
colons, spaces, or an extension, and never in a directory. In Windows 8+, as
part of updating the internal console implementation to use an I/O device (i.e.
"\Device\ConDrv"), "CONIN$" and "CONOUT$" were added to the system runtime
library's list of DOS devices, so they behave the same as other DOS device
names, including "NUL", "CON", "AUX", "PRN", "COM<1-9>", and "LPT<1-9>". This
change is undocumented.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue37517>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
