Improve error messages for Windows reserved file names #81698

Activity

1. stevendaprano commented on Jul 7, 2019

   

   stevendaprano

   on Jul 7, 2019

   MemberAuthor

   More actions

   See bpo-37515.

   Perhaps Windows builds can check for reserved file names and give a more descriptive error message in the event of IO error?

   (Eryksun also mentions two reserved names which Microsoft apparently does not document: "CONIN$" and "CONOUT$".)
2. stevendaprano

   added

   3.8 (EOL)end of lifeend of life

   OS-windows

   type-featureA feature request or enhancementA feature request or enhancement

   on Jul 7, 2019
3. eryksun commented on Jul 7, 2019

   

   eryksun

   on Jul 7, 2019

   Contributor

   More actions

   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.
4. zooba commented on Jul 9, 2019

   

   zooba

   on Jul 9, 2019

   Member

   More actions

   Presumably this is linked to bpo-37515 (why not just repurpose that one?), but I'm inclined to think this is okay provided:

   • if the operation succeeds, no error/message is displayed
   • if the operation fails, we only update the error message if one of the special filenames is the target

   So probably this ought to be a special case in PyErr_SetFromWindowsErrWithFilename(). And either we need to search the string for the special names or find an API that will clarify it (GetFileAttributes?).

   I definitely do not want every error message suggesting that this edge case may be the cause, and I don't want to prevent people using these names or purpose for their actual uses.
5. eryksun commented on Jul 10, 2019

   

   eryksun

   on Jul 10, 2019

   Contributor

   More actions

   if the operation succeeds, no error/message is displayed

   Some errors pass silently and may be confusing later on. For example, CreateDirectoryW calls NtCreateFile with the disposition FILE_CREATE and the option FILE_DIRECTORY_FILE (i.e. the call *must* create a new directory), but some non-filesystem devices ignore this and let the request succeed. For example:

   >>> os.mkdir('C:/Temp/nul')
   >>> os.mkdir('C:/Temp/conin$')
   

   Both calls 'succeed' but don't actually create a directory:

       >>> os.path.exists(r'\\?\C:\Temp\nul')
       False
       >>> os.path.exists(r'\\?\C:\Temp\conin$')
       False

   either we need to search the string for the special names or find
   an API that will clarify it

   GetFullPathNameW is a library function that shares the implementation that's used to normalize paths in a create or open context.

   If the path does not start with \\?\, then we resolve it via GetFullPathNameW. If it becomes a device path, or if the final component changes (e.g. a trailing dot or space is removed), then we can parenthetically include the resolved path. For example:

   os.stat('spam.'):

   FileNotFoundError: [WinError 2] The system cannot find the file specified: 'spam.' [resolved path: 'C:\\Temp\\spam']
   

   os.startfile('con'):

   OSError: [WinError 1200] The specified device name is invalid: 'con' [resolved path: '\\\\.\\con']
   

   os.open('C:/Temp/lpt9', 0):

   FileNotFoundError: [Errno 2] No such file or directory: 'C:/Temp/lpt9' [resolved path: '\\\\.\\lpt9']
   

   For os.open() and open(), we should switch to using PyErr_SetExcFromWindowsErrWithFilenameObject instead of PyErr_SetFromErrnoWithFilenameObject. _doserrno is valid in this context, so we should be using it anyway to retain the more specific winerror value. Then we only have to special case reserved names in the Windows-only function PyErr_SetExcFromWindowsErrWithFilenameObjects.
6. ezio-melotti

   transferred this issue fromon Apr 10, 2022