`file+noindex` parsing is broken for Windows paths

[jasagredo]

Describe the bug

The file+noindex scheme is underspecified for Windows paths. It seems to follow the file scheme (RFC 8089), but Windows paths are not properly parsed by network-uri. A path like file:///C:/some/path should produce the path C:/some/path, however it produces
/C:/some/path.

$ cabal repl network-uri
...
ghci> import Network.URI
ghci> uri = fromJust $ parseURI "file+noindex:///C:/some/path"
ghci> putStr $ unlines ["Scheme: " <> uriScheme uri, "Auth: " <> show (uriAuthority uri), "Path: " <> uriPath uri, "Frag: " <> uriFragment uri]
Scheme: local+noindex:
Auth: Just (URIAuth {uriUserInfo = "", uriRegName = "", uriPort = ""})
Path: /C:/some/path
Frag:
ghci> readFile $ uriPath uri
*** Exception: /C:/some/path: openFile: invalid argument (Invalid argument)

And if the last slash is removed, then the C: part is parsed as part of the auth:

$ cabal repl -b network-uri
...
ghci> import Network.URI
ghci> uri = fromJust $ parseURI "file+noindex://C:/some/path"
ghci> putStr $ unlines ["Scheme: " <> uriScheme uri, "Auth: " <> show (uriAuthority uri), "Path: " <> uriPath uri, "Frag: " <> uriFragment uri]
Scheme: local+noindex:
Auth: Just (URIAuth {uriUserInfo = "", uriRegName = "C", uriPort = ":"})
Path: /some/path
Frag:
ghci> readFile $ uriPath uri
"The contents of the file in C:/some/path\n"
ghci>

$ cd D:/
$ cabal repl -b network-uri
...
ghci> readFile "/some/path"
*** Exception: /some/path: openFile: does not exist (No such file or directory)

Just by luck, paths starting with / are interpreted as paths in the current drive so if we just happen to want that it might work.

If no volume or drive letter is specified and the directory name begins with the directory separator character, the path is relative from the root of the current drive.

from https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#example-ways-to-refer-to-the-same-file

The right parsing would be what file-uri does:

ghci> import System.URI.File
ghci> uri = fromRight undefined $ parseFileURI ExtendedWindows "file:///C:/some/path"
ghci> uri
FileURI {fileAuth = Nothing, filePath = "C:/some/path"}
ghci> readFile $ Data.ByteString.Char8.unpack $ filePath uri
"The contents of the file in C:/some/path\n"

Which results in a path accessible from everywhere in the system. However this is not the end of the story because:

• file-uri only allows file: schemes, it will not allow file+noindex: uris.
• The file uri RFC does not mention fragments, so file-uri does not parse those.

We can either define a parser for file+noindex from scratch, or do some tricks to parse the uri as a network-uri uri, then fabricate an intermediate uri with the file: scheme and use file-uri or something else. I just didn't want this finding to go missing again.

[jasagredo]

It probably doesn't make much sense fixing this before #8889 goes in.

[jasagredo]

Also this PR fixes the issue but in a slightly hacky way MercuryTechnologies#3. It was dropped in the end from what was merged into master

[phadej]

I don't think it make sense to support DOS filepaths. UNC paths could already work (I don't have windows machine to try).

[phadej]

Also duplicate of #7065: looks like UNC paths do work!

[jasagredo]

Thanks @phadej. I can try with UNC paths next week. Not sure if they need to be normalised or one can open a path //?/C:/some/path

[jasagredo]

@phadej It does not work with UNC paths:

ghci> printParsedFields "file+noindex:////?/C:/some/path"
Scheme: file+noindex:
Auth: Just (URIAuth {uriUserInfo = "", uriRegName = "", uriPort = ""})
Path: //
Query: ?/C:/some/path
Frag:

No matter which combination of / I use, it will consider the path part of the query. Also notice we would have to postprocess the filepath:

ghci> readFile "//?/C:/some/path"
*** Exception: //?/C:/some/path: openFile: does not exist (No such file or directory)
ghci> readFile $ normalise "//?/C:/some/path"
"The contents of the file in C:/some/path\n"

[phadej]

This special folder is accessed via the DOS device path syntax, which is one of:

\\.\C:\Test\Foo.txt \\?\C:\Test\Foo.txt

*Network.URI> fmap uriPath $ parseURI "file:////./C:/Test/Foo.txt"
Just "//./C:/Test/Foo.txt"

[jasagredo]

I see. \\.\ could indeed work. I find it quite convoluted and inconvenient for Windows users of cabal (as opposed to parsing a file uri with ExtendedWindows extension), but I agree that it would work.

Btw, where is your quote from?

[phadej]

From the already linked https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#unc-paths

[phadej]

To comment on original post

The right parsing would be what file-uri does:

It's not. file-uri says

ExtendedWindows Parses windows paths according to E.1, E.2 and E.3. Unlike the spec, posix paths are rejected.

And more importantly, we need to parse the schema first to even know we are parsing file-path like URIs. The repository location is a URL, it can be file: schema, but more often it's http or https.

---

I guess e.g. Chrome does some extra processing so file:///C:/foo.txt does work, but it's not just "always strip leading slash on Windows", as UNC paths must work too. If UNC paths work without extra processing, that's IMO good enough.

[jasagredo]

Ok, I am convinced. BTW, //./.. paths also need to be normalised before being used.