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 barneygale, eryksun, ikelos
Date 2022-02-05.23:20:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1644103221.85.0.509713169412.issue46654@roundup.psfhosted.org>
In-reply-to
Content
Builtin open() calls C open(). This C function supports whatever path types are supported natively. In Windows, C open() calls WinAPI CreateFileW(), which does not support "file://" URIs. The Windows API handles it as a relative path, which gets resolved against the current working directory. For example:

    >>> os.getcwd()
    'C:\\Temp'
    >>> nt._getfullpathname('file:////host/share/file')
    'C:\\Temp\\file:\\host\\share\\file'
    >>> nt._getfullpathname('file://host/share/file')
    'C:\\Temp\\file:\\host\\share\\file'

As to the resolved path somehow working, that generally will not be the case. Most filesystems in Windows will reject a path component named "file:" as an invalid name. The ":" character is usually disallowed in base file and directory names, since some Windows filesystems use it as a delimiter in file streams, e.g. "name:stream_name:stream_type". The default data stream in a regular file has no stream name, and its stream type is "$DATA". Thus for base name "file", the default data stream can be referenced explicitly as "file::$DATA". But just "file:", with neither a stream name nor a stream type, is an invalid name.
History
Date User Action Args
2022-02-06 00:01:02eryksununlinkissue46654 messages
2022-02-05 23:20:21eryksunsetrecipients: + eryksun, ikelos, barneygale
2022-02-05 23:20:21eryksunsetmessageid: <1644103221.85.0.509713169412.issue46654@roundup.psfhosted.org>
2022-02-05 23:20:21eryksunlinkissue46654 messages
2022-02-05 23:20:21eryksuncreate