comment

doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_4_f2bd555ca36b42dac6a213e7c947f1f9._comment

@@ -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.
+"""]]