Added a comment
This commit is contained in:
parent
e00aa8ed29
commit
9ce3cc912b
1 changed files with 22 additions and 0 deletions
|
@ -0,0 +1,22 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.244"
|
||||
subject="comment 3"
|
||||
date="2014-04-02T19:18:19Z"
|
||||
content="""
|
||||
Yes, --relaxed bypasses the code that uses curl to check the file size.
|
||||
|
||||
Ok, I have figured out what's going on.
|
||||
|
||||
git annex addurl --file foo ftp://host # this succeeds
|
||||
|
||||
run the command a second time, and it fails. Why? Because the file is already present in the annex, and you are running addurl in a different mode. In this mode, it is adding a *new* url to the file in the annex. (In this particular case, the new and old url are the same, but it's possible to see this bug in cases where they are not, too.)
|
||||
|
||||
As a sanity check, when adding a new url to an existing file, git-annex wants to check that the new url has the same size as the file. Otherwise it surely has different content. However, as I noted this ftp server is returning a weird 350 response when curl is used to try to get the size of the url. So that fails, and git-annex cannot add the new url to the file. Which would be pointless in this case anyway, since it's the same as the old url.
|
||||
|
||||
So, I can fix two things. I can make it detect when the url it's adding to an existing file in the annex is already a known url of that file, and skip doing anything in this case since it would be a no-op anyway. Done that.
|
||||
|
||||
And, I can improve the error message so the user is not confused about what they're asking git-annex to do, and why it's unable to. Fixed that.
|
||||
|
||||
This leaves the question of why curl sees a 350 code from this ftp server. But since it doesn't cause problems when using addurl, with or without --file to download the file from it, I think it's best to punt on that one.
|
||||
"""]]
|
Loading…
Reference in a new issue