Path prefixed by `\\.\` is not normalised on Windows

[jasagredo]

I don't see this in the haddocks, is it expected?

ghci> System.FilePath.Windows.normalise "\\\\.\\C:/foo.txt"
"\\\\.\\C:/foo.txt"
ghci> System.FilePath.Windows.normalise "C:/foo.txt"
"C:\\foo.txt"

[jasagredo]

I can confirm the same works with \\?\:

ghci> System.FilePath.normalise "\\\\?\\C:/foo.txt"
"\\\\?\\C:\\foo.txt"
ghci> System.FilePath.normalise "\\\\.\\C:/foo.txt"
"\\\\.\\C:/foo.txt"

Probably because of this:

ghci> System.FilePath.isDrive "\\\\.\\C:\\"
False
ghci> System.FilePath.isDrive "\\\\?\\C:\\"
True
ghci> System.FilePath.splitDrive "\\\\?\\C:/foo.txt"
("\\\\?\\C:/","foo.txt")
ghci> System.FilePath.splitDrive "\\\\.\\C:/foo.txt"
("\\\\.\\","C:/foo.txt")

[hasufell]

Those behaviors are a little inconsistent.

\\.\ should be treated mostly the same as \\?\.

But the latter has an interesting property: https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#skip-normalization

But as the windows api documentation says, they're still normalized when passed to GetFullPathName. So maybe we should do the same.

But it would be kind of a breaking change.

Sometimes people rely on "bugs". Is this a bug? It's debatable.

[jasagredo]

My preference would be to treat both the same.

I think at the very least this behavior should be documented in the examples.

It is counterintuitive.

[hasufell]

I think at the very least this behavior should be documented in the examples.

well, the thing is that it only behaves so by accident and the code doesn't really ensure this properly... so I find it hard to document it, given it's kinda a quirk

I haven't made up my mind yet what the best solution is.

[hasufell]

@Mistuke any opinions?