Windows drive-relative pathlib.Path.resolve(strict=False) resolves incorrectly in pyfakefs 6.2.0

[b-morgenthaler]

Describe the bug

On Windows, pathlib.Path.resolve(strict=False) resolves drive-relative paths incorrectly when pyfakefs is active.

A Windows path like c:test\test_data\dummy1.xml is drive-relative, not absolute. With the current directory set to C:\test, CPython's real pathlib resolves it to:

C:\test\test\test_data\dummy1.xml

With pyfakefs 6.2.0 active, the same path resolves to:

c:\est\test_data\dummy1.xml

The first character of the relative path component (t in test) appears to be dropped, and the path is treated like it starts at the drive root.

This looks like a regression from pyfakefs 6.1.4 to 6.2.0. The same test passed with pyfakefs 6.1.4 and fails with pyfakefs 6.2.0.

How To Reproduce

Please run this on Windows:

from pathlib import Path
import os

from pyfakefs.fake_filesystem_unittest import Patcher


with Patcher() as patcher:
    fs = patcher.fs
    root = Path("/test")
    fs.create_file(root / "test_data" / "dummy1.xml")
    os.chdir(root)

    drive = Path.cwd().drive
    path = Path(f"{drive.lower()}test\\test_data/dummy1.xml")
    resolved = path.resolve(strict=False)

    print("cwd:", Path.cwd())
    print("path:", path)
    print("resolved:", resolved)

    assert str(resolved) == r"C:\test\test\test_data\dummy1.xml"

Actual output with pyfakefs 6.2.0:

cwd: C:\test
path: c:test\test_data\dummy1.xml
resolved: c:\est\test_data\dummy1.xml

Expected output:

cwd: C:\test
path: c:test\test_data\dummy1.xml
resolved: C:\test\test\test_data\dummy1.xml

For comparison, outside pyfakefs, Path.resolve(strict=False) resolves the drive-relative path relative to the current directory on that drive as expected.

Your environment

Output from the affected environment:

platform: Windows
Python: 3.12.12
pyfakefs: 6.2.0
pytest: 9.0.3

[b-morgenthaler]

Additional data point after testing older 6.1.x releases:

In our project, pyfakefs==6.1.5 shows multiple Windows path resolution regressions in the same test module, but not the exact drive-relative failure described in this issue.

Examples of the observed wrong results with 6.1.5:

expected: /C/some/path
actual:   /C/me/path

expected: /Y/some/path/to/be/converted
actual:   /C/some/path/to/be/converted

expected: /localhost/computer/some/path
actual:   /C/ocalhost/computer/some/path

With pyfakefs==6.1.6, these three cases pass again, but the drive-relative case from this issue fails.

Observed with 6.1.6:

expected: /C/test/test/test_data/dummy1.xml
actual:   /C/est/test_data/dummy1.xml

So the timeline from our tests is:

6.1.4: all affected tests pass
6.1.5: several Windows path resolution tests fail
6.1.6: only the drive-relative path case fails
6.2.0: the same drive-relative path case still fails

This suggests that there were broader Windows path resolution regressions in 6.1.5, most of which were fixed in 6.1.6, while the drive-relative Path.resolve(strict=False) case remained broken.

[mrbean-bremen]

Thanks! This indeed looks like an incomplete fix - obviously missed some use cases here. This fix had more impact than I had expected...

[mrbean-bremen]

I can reproduce it, and I have a local fix, but that only works from Python 3.12 upward. Earlier versions use a different path, and I probably need to restructure this to work for all versions. This may take a bit, and I will probably not get much time for it before the weekend.

[b-morgenthaler]

I can only speak for myself, but it's fine for my projects to stay on 6.1.4 a bit more. Better to take the time to make the fix robust