Failed to find real location of `python.exe` on a RAM disk

[nedman47]

Bug report

Bug description:

# Add a code block here, if required

Starting with 13.0 Python I get the warning "failed to find real location of python.exe" but only if I run it from a ram disk, never when i run it from a network share. I wrote an editor in Python back in 2017 and it was very fast except for startup, which took as long as 700 msec. I knew Microsoft C was fast in part because its DLLs were preloaded into memory. One day I was watching a Dave Plummer video on YouTube and he mentioned ram drives which I hadn't thought about since the days of MS-DOS. I found and installed IMDISK on Windows 10, and later Windows 11. The editor, and everything else, runs instantly and I've never had any problems with Python running from a ram disk. So, I'm writing to see if you guys could either make an exception for ram drives, or provide a way to turn off that warning message. Thanks in advance.

CPython versions tested on:

3.13

Operating systems tested on:

Windows

[zooba]

Hmm, if you're seeing that message, it must mean that we can't CreateFile or GetFinalPathNameByHandleW on your RAM disk. I've not come across that issue before - those are very common APIs that ought to work.

If you ignore the message on startup and do os.path.realpath(sys.executable) does it work? Or do you get a more specific error?

[ChrisDenton]

This is a very common failure mode for IMDISK. It doesn't integrate with the mount manager at all so it's impossible for GetFinalPathNameByHandleW to get the DOS drive letter.

The documentatiom even has a section on this which suggests getting the NT path then manually looking up the drive letter: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlew#remarks

Some third-party drivers can create a drive letter or mount point without using the Mount Manager. If the Mount Manager was not used to create the drive, then VOLUME_NAME_DOS or VOLUME_NAME_GUID will not succeed; only VOLUME_NAME_NT will be available. To determine the drive letter for the volume device path, use the QueryDosDevice function on every drive letter until a matching device name is found

[nedman47]

import os
import sys
print (os.path.realpath (sys.executable))

It printed "r:\python\python313\python.exe"

WMIC and PowerShell both see drive R:

Drive Snapshot is able to create and restore images as if it were a normal drive.

I've used IMDISK with Python 312, 311, and 310 for years with no apparent harm, and certainly no failure to locate messages. This is new with 313.

[ChrisDenton]

Try:

print (os.path.realpath (sys.executable, strict=True))

os.path.realpath has fallbacks for if GetFullPathNameW fails which can be disabled when setting strict to True.

[nedman47]

import os
import sys

print (os.path.realpath (sys.executable))
print (os.path.realpath (sys.executable, strict=True))

----- OUTPUT -----

z:\python\windows\nued>py312 zzz.py
r:\python\python312\python.exe
Traceback (most recent call last):
File "z:\python\windows\nued\zzz.py", line 6, in
print (os.path.realpath (sys.executable, strict=True))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 727, in realpath
OSError: [WinError 1] Incorrect function: 'r:\python\python312\python.exe'

z:\python\windows\nued>py313 zzz.py
Failed to find real location of r:\python\python313\python.exe
r:\python\python313\python.exe
Traceback (most recent call last):
File "z:\python\windows\nued\zzz.py", line 6, in
print (os.path.realpath (sys.executable, strict=True))
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 726, in realpath
OSError: [WinError 1] Incorrect function: 'r:\python\python313\python.exe'

Running the same code with Python 312 and 313, we see that they both give the error under strict=True, but 312 is silent without it, while 313 gives the "failed to find real location" warning, but works anyway.

[zooba]

I think it's probably fine to suppress the warning if ex.winerror == 1.

PRs welcome if anyone wants to do it - this should be a simple enough change. The tricky bits are that winerror won't exist on non-Windows, so we probably want to use getattr, and updating getpath.py requires a rebuild of CPython each time or changes won't take effect.

[nedman47]

I rooted around on the IMDISK website and think I understand the problem. It describes itself as "only a volume". No partition table and no disk. It's easy to imagine the Windows Disk Manager seeing it as a few methods shy of an object and not listing it. But if Python is able to find the volume anyway, I would think it is safe to disable the warning.

However, I did more digging and found another ramdisk from SoftPerfect. Very preliminary testing shows it does NOT give the warning.

[zooba]

My main consideration is whether the warning on startup is helpful to let users know that other functionality may not work? If it helps convince IMDISK to add better integration then I'd probably count that as a win ;)

I guess since it's only os.path.realpath (and anything that uses it - venv, IIRC, perhaps others) that will not behave as expected (returning unresolved paths) that we should probably still suppress the warning.