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