``ntpath.realpath()`` doesn't always normalize the case

[moi15moi]

Bug report

Bug description:

In some case, ntpath.realpath doesn't normalize the case like the one in the windows file explorer.

Example

from ntpath import realpath
print(realpath("c:\\windows\\notepad.exe"))

Expected result: C:\WINDOWS\notepad.exe
Result: C:\Windows\notepad.exe

I took the expected result from the file explorer:

Note

Under the hood, cpython use GetFinalPathNameByHandle and from what I can see, it has the same problem

CPython versions tested on:

3.10

Operating systems tested on:

Windows 10 version 22h2 build 19045.3930

[terryjreedy]

On my US version Windows 10, the directory is consistently C:\Windows, in both directory/file listings and property dialogs. Title case is also used for most other directories, such as Program Files and Users. The all-caps renditions strikes me as a localized possibly display-only relic of earlier Windows or even DOS. Lets see what a Windows expert says.

[zooba]

We treat the OS APIs as canonical, and in general pass parameters between them directly without doing additional processing.

In this case, as pointed out, the API result is consistent. The UI display is the odd one out, but unless its logic is encoded into a native API, there's no way we can replicate it.

[moi15moi]

@zooba After some research, I found that the Windows Shell API return the right result. Here is a sample on how to use it

#include <Windows.h>
#include <Shlobj.h>
#include <iostream>

int main() {
    HRESULT hr;
    hr = CoInitialize(NULL);
    if (FAILED(hr))
        return hr;

    const wchar_t* filePath = L"c:\\windows\\notepad.exe";

    LPITEMIDLIST pidl;
    hr = SHParseDisplayName(filePath, NULL, &pidl, 0, NULL);
    if (FAILED(hr))
        return hr;

    wchar_t normalizeFilePathCase[MAX_PATH];

    if (!SHGetPathFromIDListW(pidl, normalizeFilePathCase))
        return -1;

    std::wcout << normalizeFilePathCase << std::endl;

    CoTaskMemFree(pidl);
    CoUninitialize();

    return 0;
}

Result

But, this method has some problem. It doesn't accept all the possible File path formats on Windows systems.

It accepts:

• Traditional DOS paths (ex: C:\Windows\notepad.exe)
• UNC paths (ex: \\\\192.168.1.20\\Plex Content\\arialbi.ttf)

Does not accepts (SHParseDisplayName return a error):

• VOLUME_NAME_GUID (ex: Volume{ cb34f3a1 - 0000 - 0000 - 0000 - 300300000000 }\Windows\notepad.exe)
• VOLUME_NAME_NT (ex: \Device\HarddiskVolume6\Windows\notepad.exe)
• Traditional DOS paths and UNC paths with the prefix \\?\ or \\?\UNC.

To bypass the problem, we could remove the prefix by calling PathCchStripPrefix.
But for VOLUME_NAME_GUID/VOLUME_NAME_NT path, I don't what approch we should use. Does cpython even support these file path format?

Edit
This is also possible. With this solution, we would not be limited to MAX_PATH

#include <Windows.h>
#include <Shlobj.h>
#include <iostream>
#include <Objbase.h>

int main() {
    HRESULT hr;
    hr = CoInitialize(NULL);
    if (FAILED(hr))
        return hr;

    const wchar_t* filePath = L"C:\\windows\\explorer.exe";

    IShellItem* pItem = nullptr;
    hr = SHCreateItemFromParsingName(filePath, nullptr, IID_PPV_ARGS(&pItem));
    if (FAILED(hr))
        return hr;

    LPWSTR ppszName;
    hr = pItem->GetDisplayName(SIGDN_FILESYSPATH, &ppszName);
    if (FAILED(hr))
        return hr;

    std::wcout << ppszName << std::endl;

    CoTaskMemFree(ppszName);
    pItem->Release();

    CoUninitialize();

    return 0;
}

[zooba]

The Windows Shell API is very heavyweight and expensive to call, and adding CoInitialize calls is a breaking change that we need to do very responsibly (or run on a new temporary thread, which makes this even more expensive).

I'm yet to hear a reason why the Property Window should be treated as canonical here, rather than the API whose job is to return the correct path.

[moi15moi]

I'm yet to hear a reason why the Property Window should be treated as canonical here, rather than the API whose job is to return the correct path.

I don't have any good reason. I just tought that the file explorer was the source of truth.
But, I checked in the Windows Registry (a random key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\KnownManagedDebuggingDlls) and actually, it list C:\WINDOWS as C:\Windows.

So, I guess it is a bug in the shell or something else, but still, it is a bit weird.