This commit is contained in:
Joey Hess 2023-03-13 15:40:18 -04:00
parent f1b678face
commit c76d44d7e1
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38

View file

@ -0,0 +1,32 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2023-03-13T18:54:33Z"
content="""
Wikipedia seems to be wrong about that.
I took a quick look at <https://datatracker.ietf.org/doc/html/rfc8089#appendix-E.2>
and it says that "file:c:/path/to/file" is a valid URI on Windows. And it will be
parsed ok by git-annex. So you could just use those.
The RFC does say that "file:///c:/path/to/file" should also be supported.
(Though I don't understand its reference to the "path-absolute" rule.)
I don't know if network-uri could be made to support that, it seems that
it would have to handle windows and non-windows differently. Because on linux,
"file:///c:/path/to/file" should parse to a path "/c:/path/to/file",
which is after all a valid path if you choose to have a `/c:` directory!
But network-uri is a pure uri parser and it does not seem right for it to parse
the same uri two different ways depending on the OS it's running on. And it doesn't
special-case handling of file urls at all, it only implements RFC3986.
We could try opening an issue at <https://github.com/haskell/network-uri/issues>
and find out what its maintainer thinks.
I suppose that git-annex, when running on windows, every place after it parses an
url could:
1. Check if it's a file: url
2. If the path starts with "/DRIVE:", remove the leading "/"
Yugh.
"""]]