blob: 5097e2e16ac7357088588f319abfffdb31753495 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2015-09-09T16:36:13Z"
content="""
I can't reproduce that behavior on linux.
joey@darkstar:~/tmp/xx>git annex addurl --file=annexed file:///./data
addurl annexed (downloading file:///./data ...)
curl: (37) Couldn't open file /data
Here, curl seems to be doing the right thing; the url is not relative; it's
for `/./data`, which doesn't exist.
Relative `file:` urls shouldn't be valid at all, I think?
---
For checking if a file: url exits, git-annex parses the url and stats
the file itself. The first screenshot
shows this check for file: url existance failing on Windows for
the url `file:///C:/tmp/test/test.dat`
I guess this might come down to problems with parsing file: urls on
Windows; seems especially complicated by drive letters. git-annex and curl
seem to parse this url in different ways.
Checking how that url parses, the uriScheme is "file:" and the uriPath is
"/C:/tmp/test/test.dat". So, it seems clear why it fails to stat that file.
Is there actually a valid way to produce a file: url that refers to a drive
letter? curl seems to think so, since it found the file when `git annex
addurl` ran it. I don't know if the above parse is valid, but it's not
git-annex's code doing the parse, but the URI parsing library.
(Possibly related bug report:
<http://git-annex.branchable.com/bugs/git_annex_test_fails_when_run_through_powershell/>
)
"""]]
|
