`canonicalizePath "\\\\localhost\\C$\.."` incorrectly produces `"\\\\localhost\\"`

[andreasabel]

Lifted from agda/agda#8116 (comment):

import System.Directory
import System.FilePath

list :: FilePath -> IO ()
list dir = do
    putStrLn $ replicate 66 '-' 
    putStrLn dir
    putStrLn $ replicate 66 '-'
    mapM_ (putStrLn . ("- " ++)) . take 2 =<< listDirectory dir

up :: FilePath -> IO FilePath
up dir = canonicalizePath (dir </> "..")

upIO :: IO FilePath -> IO FilePath
upIO = (up =<<)

-- https://stackoverflow.com/questions/2787203/unc-path-to-a-folder-on-my-local-computer
main :: IO ()
main = do
    -- let dir = "\\\\?\\C:\\Users\\admin"
    let dir = "\\\\localhost\\C$\\Users\\admin"
    let ups = take 4 $ iterate upIO (pure dir)
    mapM_ (list =<<) ups

This produces:

------------------------------------------------------------------
\\localhost\C$\Users\admin
------------------------------------------------------------------
- VirtualBox VMs
- Videos
------------------------------------------------------------------
\\localhost\C$\Users
------------------------------------------------------------------
- Public
- desktop.ini
------------------------------------------------------------------
\\localhost\C$
------------------------------------------------------------------
- Windows
- Users
------------------------------------------------------------------
\\localhost\
------------------------------------------------------------------
test-directory: Uncaught exception ghc-internal:GHC.Internal.IO.Exception.IOExce
ption:

\\localhost\: getDirectoryContents:findFirstFile: does not exist (The specified
path is invalid.)

While handling findFirstFile: does not exist (The specified path is invalid.)

In contrast, "\\\\?\\C:\\Users\\admin" is treated correctly. Canonicalization turns this into C:\Users\admin.

There is a suspicion that canonicalizePath does not work correctly on UNC pathes.

The unitests for canonicalizePath seem to steer clear of UNC paths, except for this one:

directory/tests/CanonicalizePath.hs

Lines 164 to 166 in 6442a3c

	when isWindows $ do
	-- https://github.com/haskell/directory/issues/170
	T(expectEq) () "\\\\localhost" =<< canonicalizePath "\\\\localhost"

[andreasabel]

ATTN: @Rufflewind

[Rufflewind]

There seems to be an inconsistency in how GetFullPathNameW handles \\?\ paths. According to Maximum Path Length Limitation \\localhost\C$\.. is equivalent to \\?\UNC\localhost\C$\.., which is a conversion that directory does behind the scenes to bypass the MAX_PATH limitation. Yet, GetFullPathNameW treats them differently:

#include <windows.h>
#include <stdio.h>

int main(void)
{
    wchar_t buf[512];
    const wchar_t *input;

    input = L"\\\\localhost\\C$\\..";
    if (!GetFullPathNameW(input, sizeof(buf) / sizeof(*buf), buf, NULL)) {
        wprintf(L"GetFullPathName: %d\n", GetLastError());
    }
    wprintf(L"Output: %ls\n", buf);

    input = L"\\\\?\\UNC\\localhost\\C$\\..";
    if (!GetFullPathNameW(input, sizeof(buf) / sizeof(*buf), buf, NULL)) {
        wprintf(L"GetFullPathName: %d\n", GetLastError());
    }
    wprintf(L"Output: %ls\n", buf);

    return 0;
}

$ /mingw64/bin/cc main2.c && ./a
Output: \\localhost\C$
Output: \\?\UNC\localhost

The first output is right, whereas the second is wrong: C$ isn't supposed to get chopped off.

I don't see a practical way to fix this bug without turning off the \\?\ prefix for UNC paths, which in turn would disable the MAX_PATH-limitation bypass.

[andreasabel]

Is there a way to contact the Microsofters about this behavior?

[Rufflewind]

Is there a way to contact the Microsofters about this behavior?

I believe Feedback Hub is their official support channel: https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332

[andreasabel]

Mmh, that looks like a end-user issue reporter. So maybe stackoverflow is the better forum.