Please describe the problem.
some tests started to fail in datalad when tried current master version of annex
What version of git-annex are you using? On what operating system?
6.20171205+gitgcf05ebbeb-1~ndall+1
Please provide any additional information below.
(git-annex)hopa:/tmp/datalad_temp_test_AnnexRepo_web_remoteRusdWA[master]git
$> git annex whereis --json 127.0.0.1_about.txt
{"command":"whereis","note":"web: http://example.com/someurl\nweb: yt:http://127.0.0.1:33587/about.txt\n","success":true,"untrusted":[],"key":"SHA256E-s14--198775960d0d9827f134da4e219e5793949d24b62bfcb92aa9e2dc16d411b776.txt","whereis":[{"here":false,"uuid":"00000000-0000-0000-0000-000000000001","urls":["http://example.com/someurl","yt:http://127.0.0.1:33587/about.txt"],"description":"web"}],"file":"127.0.0.1_about.txt"}
$> git annex whereis 127.0.0.1_about.txt
whereis 127.0.0.1_about.txt (1 copy)
00000000-0000-0000-0000-000000000001 -- web
web: http://example.com/someurl
web: yt:http://127.0.0.1:33587/about.txt
This is a new behavior, this test was passing before, and I do not think we suggested that those test files are anyhow related to youtube before.
Some tests also failed related to our datalad archives git annex special remote but I didn't look into them yet -- I guess though that it is related
Reporoduced by putting "Lots of abouts" in a http://localhost/about.txt file, and running git annex addurl --file with an existing file and that url.
Thanks for the fix... seems to be a bit incomplete though -- in the --fast mode, url still has yt: prefix, reflected in the key as well:
That one happened with
git annex addurl --fast $url
so a different code path. Had to add a html page check to youtubeDlFileName to fix it.ok, tested with 6.20171208+gitg01f78e877-1~ndall+1 -- --fast mode issue is indeed resolved. Thanks! Failing tests now only relate to our special remote (datalad-archives) which interfaces urls, so I thought it might relate... I will try to distill more info tomorrow unless you beat me to it figuring out where that regression could be (upon quick look didn't spot any yt: anywhere, so probably another issue)
ok, first initial bit of information: there is a difference in interactions with the special remote now. Here is the diff between old and new runs (sorry - content was also changing so there is difference in keys as well):
our test verifies that annex refuses to drop the content if we remove the dl+archive link for the key, and now it fails
The diff shows
git annex whereis
used to send CLAIMURL to the external, and no longer does.Reproduction recipe using git-annex-remote-ipfs:
Which results in
git annex whereis somefile
saying it's present in ipfs, but not listing the ipfs url for it. And again, whereis does not sent CLAIMURL.And, in log.web, I see why:
That is not an OtherDownloader url, it's lacking the ":" prefix.
This seems to be particular to the addurl --relaxed --file code path; letting addurl add a new file does result in an OtherDownloader url being recorded.
I guess the reason the test suite then fails is, the url it removes is not the one git-annex recorded, and so git-annex still thinks it's at the wrongly recorded url, and so dropping succeeds.
Above problem fixed in [[!commit bd7f8be121a5cd310ffbc32c6020326ef437a151]
Good thing you have such a good test suite.