This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients eryksun, jaraco, paul.moore, steve.dower, tim.golden, zach.ware
Date 2020-08-08.19:15:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1596914105.65.0.212673205852.issue41509@roundup.psfhosted.org>
In-reply-to
Content
> I suspect the Windows version is using some API that strips whitespace 
> from the filename before performing a relative path. 

When normalizing a path, the Windows API strips trailing dots and spaces from the final component. Apparently it also strips a single trailing dot from other components if the dot is preceded by any character other than a dot. For example:

    >>> nt._getfullpathname('foo../bar./bam. . .')
    'C:\\foo..\\bar\\bam'

The way to create or open a file or directory with a name that ends with a dot or space is to prefix the path with exactly "\\\\?\\". However, it is strongly advised to never create a file or directory with such an abnormal name. Note that this prefix only affects using a path in an open/create context. It doesn't prevent an explicit normalization, such as the following:

    >>> nt._getfullpathname('\\\\?\\C:/foo../bar./bam. . .')
    '\\\\?\\C:\\foo..\\bar\\bam'

> I wouldn't expect Windows to be performing normalization of paths in 
> relpath, but it seems it does. 

ntpath.relpath calls ntpath.abspath, which calls nt._getfullpathname in Windows. On POSIX systems, ntpath.abspath is ntpath._abspath_fallback.  The latter and ntpath.normpath need to be improved to better implement Windows path normalization. 

normpath should not exclude paths that start with '\\\\.\\' and '\\\\?\\', and it should trim trailing spaces and dots from component names to match how Windows normalizes a path. 

_abspath_fallback should default to the root directory for drive relative paths (e.g. "C:foo" -> "C:\\foo"). It should also substitute a device path if the final component in a relative or drive-letter path (but not a UNC path or device path) matches a known DOS device name. Matching a DOS device name ignores everything after a dot or colon that's preceded by zero or more spaces (e.g. "con .anything" -> "\\\\.\\con" and "nul:anything" -> "\\\\.\\nul").
History
Date User Action Args
2020-08-08 19:15:05eryksunsetrecipients: + eryksun, paul.moore, jaraco, tim.golden, zach.ware, steve.dower
2020-08-08 19:15:05eryksunsetmessageid: <1596914105.65.0.212673205852.issue41509@roundup.psfhosted.org>
2020-08-08 19:15:05eryksunlinkissue41509 messages
2020-08-08 19:15:05eryksuncreate