gh-129333: fix import error over nfs on Windows

[ChrisDenton]

On Windows, getpath_realpath uses GetFinalPathNameByHandleW to resolve paths. This returns paths starting with a \\?\ prefix, which is usually not what we want.

This change attempts to remove the prefix for \\?\UNC\ paths. A similar thing was already done for drive paths such as \\?\C:\.

• Issue: python 3.13.1 giving import error over nfs [windows] #129333

[ghost]

All commit authors signed the Contributor License Agreement.

[ChrisDenton]

The test failures in free-threading look unrelated to my eye but maybe I'm missing some context. E.g. I'm not sure how this change could cause cause a concurrency issue:

     self._send_bytes(m[offset:offset + size])
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\a\cpython\cpython\Lib\multiprocessing\connection.py", line 293, in _send_bytes
    raise ValueError("concurrent send_bytes() calls "
                     "are not supported")
ValueError: concurrent send_bytes() calls are not supported

[FFY00]

@eryksun, would you mind having a look at this one? Thanks!

[FFY00]

The test failures in free-threading look unrelated to my eye but maybe I'm missing some context.

I triggered a re-run, let's see if it reproduces.

[FFY00]

@nineteendo could also use your input, if you have time to look at this. Cheers!

[nineteendo]

Well, I can't test this on my machine because python crashes with these warnings after the build (his is not a new issue):

C:\Users\wanne\cpython\PCbuild\python.vcxproj(134,5): warning MSB3073: The command "setlocal
C:\Users\wanne\cpython\PCbuild\python.vcxproj(134,5): warning MSB3073: set PYTHONPATH=C:\Users\wanne\cpython\Lib
C:\Users\wanne\cpython\PCbuild\python.vcxproj(134,5): warning MSB3073: "C:\Users\wanne\cpython\PCbuild\amd64\python.exe" "C:\Users\wanne\cpython\PC\validate_ucrtbase.py" ucrtbase" exited with code -1073741819 
.

You still need to add tests though.

[ChrisDenton]

You still need to add tests though.

I'm not sure how to add tests. realpath requires that the path really exist on a network path. We can't fake it because the point of realpath is to resolve to the real path.

[FFY00]

Is there no other way to get GetFinalPathNameByHandleW to return UNC paths?

[FFY00]

Well, I can't test this on my machine because python crashes with these warnings after the build (his is not a new issue):

Is it fixed in main? If so we can sync the PR, so that the fix is included.

[nineteendo]

No, this issue is still open: #123414

UPDATE: fixed by creating a clean clone, but I can't install Python libraries it seems

[ChrisDenton]

Is there no other way to get GetFinalPathNameByHandleW to return UNC paths?

Hmm... maybe I could try using a \\localhost\c$ path. I'll experiment.

[ChrisDenton]

That seems to work but the next problem I'm encountering is that there doesn't appear to be any existing unit tests for the C implementation of realpath (or any of the other functions in getpath.c) and I don't know how to add them. The test_getpath.py shims them for its testing.

I could maybe test using sysconfig::get_paths() but that means we'd need to run the test python using a \\?\UNC\localhost\ style path and not all drives support that (iirc dev drives don't). So it might be a bit flaky.

[ChrisDenton]

This can be tested locally without needing to import anything by starting python with a \\?\UNC path. E.g. if the build directory is in C:\Users\Chris\Python\PCBuild\amd64\python.exe then run:

\\?\UNC\localhost\c$\Users\Chris\Python\PCBuild\amd64\python.exe -c "import sysconfig; print(sysconfig.get_paths()['include'])"

This should print the simplified path: \\localhost\c$\Users\Chris\Python\Include. Whereas before this change it will have the long \\?\UNC path.

However, this relies on the drive supporting \\locahost.