I don't see how ntpath._getfinalpathname_nonstrict() is responsible for removing the "\\?\" prefix, unless maybe there's something wrong with the target path of the "media" symlink.

A symbolic link reparse point contains a substitute path that the system uses, plus an optional print path for display¹. What you see in the shell is the print path, but os.readlink() returns the substitute path.

What is the result of os.readlink(media_fn)?

As the log indicates, os.path.realpath returns without a prefix.

It's a known issue (#89760) that ntpath.realpath() mistakenly strips the prefix from some device paths for which the prefix must be retained. But that's unrelated to the given example in which the prefix gets stripped by ntpath._getfinalpathname_nonstrict().

What is the result of os.readlink(media_fn)?

>>> os.readlink('media')
'\\ContainerMappedDirectories\\93AA221C-4061-460F-8C4E-A2EAC1BF3324'

I read a code of ntpath._getfinalpathname_nonstrict(), perhaps the bug is caused by os.readlink behaviors.

The code of ntpath.realpath() processes L702-L706(Python3.11.0 amd64) because _getfinalpathname() causes FileNotFoundError (The specified path is symlink to DOS devices path that starts with '\?\Some without ":"').

        except OSError as ex:
            if strict:
                raise
            initial_winerror = ex.winerror
            path = _getfinalpathname_nonstrict(path)

That calls _getfinalpathname_nonstrict() and _getfinalpathname_nonstrict() calls os.readlink().

It's a known issue (#89760) that ntpath.realpath() mistakenly strips the prefix from some device paths for which the prefix must be retained. But that's unrelated to the given example in which the prefix gets stripped by ntpath._getfinalpathname_nonstrict().

I know and read #89760 but the bug is remained even if patch #89760 (comment).

This appears to be a shortcoming in os.readlink(), but a problem that's uncommon in practice. Normal symlinks created by WinAPI CreateSymbolicLinkW() are restricted to target a volume device name in NT's "\??\" directory, which contains local and global aliases for native NT device names, such as "\??\C:" -> "\Device\HarddiskVolume2". However, when manually creating a symlink via FSCTL_SET_REPARSE_POINT, it's possible to target an arbitrary NT path instead of a "\??\" prefixed path.

If the reparse point is a symlink with SYMLINK_FLAG_RELATIVE set in Flags, and the substitute path is a rooted path such as "\spam", then readlink() has to return the rooted path "\spam". This path is relative to the volume device of the opened path of the symlink. We currently implement this, except we don't check for SYMLINK_FLAG_RELATIVE.

If the reparse point is a mountpoint or if it's a symlink without SYMLINK_FLAG_RELATIVE set in Flags, and the substitute path is a rooted path such as "\spam", then readlink() has to prepend the prefix "\\?\GLOBALROOT" to the substitute path. Currently this is not implemented.

Assuming the target of "media" really exists, then the following stat() call should work:

os.stat(r'\\?\GLOBALROOT\ContainerMappedDirectories\93AA221C-4061-460F-8C4E-A2EAC1BF3324')