Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
nedman47 opened this issue Jan 14, 2025 · 4 comments
Open

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

nedman47 opened this issue Jan 14, 2025 · 4 comments
Labels
OS-windows topic-installation type-bug An unexpected behavior, bug, or error

Comments

@nedman47
Copy link

nedman47 commented Jan 14, 2025

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

@nedman47 nedman47 added the type-bug An unexpected behavior, bug, or error label Jan 14, 2025
@picnixz picnixz changed the title failed to find real location Failed to find real location of python.exe on a RAM disck Jan 14, 2025
@picnixz picnixz changed the title Failed to find real location of python.exe on a RAM disck Failed to find real location of python.exe on a RAM disk Jan 14, 2025
@zooba
Copy link
Member

zooba commented Jan 14, 2025

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
Copy link

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
Copy link
Author

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
Copy link

ChrisDenton commented Jan 15, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OS-windows topic-installation type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

5 participants