Merge branch 'master' of ssh://git-annex.branchable.com

This commit is contained in:
Joey Hess 2023-04-05 11:04:55 -04:00
commit 06c584a267
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 149 additions and 0 deletions

View file

@ -0,0 +1,62 @@
[[!comment format=mdwn
username="jkniiv"
avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
subject="comment 3"
date="2023-04-05T09:42:11Z"
content="""
I can confirm that things seem to be AOK now:
[[!format sh \"\"\"
H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex-sync
merge synced/master (Merging into master...)
Merge made by the 'ort' strategy.
Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-02-02.mrimg | 1 -
Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-03-03.mrimg | 1 -
Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-04-04.mrimg | 1 -
Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-05-05.mrimg | 1 -
Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-06-06.mrimg | 1 -
Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-07-07.mrimg | 1 -
Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-08-08.mrimg | 1 -
7 files changed, 7 deletions(-)
delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-02-02.mrimg
delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-03-03.mrimg
delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-04-04.mrimg
delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-05-05.mrimg
delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-06-06.mrimg
delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-07-07.mrimg
delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-08-08.mrimg
(Merging into adjusted branch...)
Updating a21ddee..445c0c9
Fast-forward
ok
pull k-levyn-annex2
From k:\Reflect-varmistukset
e420747..6621032 git-annex -> k-levyn-annex2/git-annex
6cab55f..7638c8c master -> k-levyn-annex2/master
6cab55f..7638c8c synced/master -> k-levyn-annex2/synced/master
ok
git-annex: .git\HEAD: openFile: resource busy (file is locked)
H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
10.20230329-g000723d96
H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
10.20230330-g3eb51ee92
H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex-sync
pull k-levyn-annex2
ok
push k-levyn-annex2
Enumerating objects: 11, done.
Counting objects: 100% (11/11), done.
Delta compression using up to 4 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 810 bytes | 405.00 KiB/s, done.
Total 7 (delta 4), reused 0 (delta 0), pack-reused 0
To k:\Reflect-varmistukset
e420747..6621032 git-annex -> synced/git-annex
7638c8c..73de8e2 master -> synced/master
ok
H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
10.20230330-g3eb51ee92
\"\"\"]]
Thank you so much, Joey, well done! 🎉
"""]]

View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 2"
date="2023-04-04T20:15:59Z"
content="""
yet to re-review that reasoning, but does it mean that to merely register a URL client needs to
- call `annex registerurl`
- inspect to which remote URL was added/was claimed (is there a way? `whois` is silent)
- if it was claimed by some special remote other than web -- use `annex setpresentkey`?
Sounds like too much / too fragile, and somewhat different from how `addurl` behaves which does it all just fine regardless either it is web or some claimurl'ed remote.
"""]]

View file

@ -0,0 +1,35 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 3"
date="2023-04-05T00:30:00Z"
content="""
So to some degree it is a regression / broken behavior which initially worked just fine with registerurl -- tried the 6.20180913+git149-g23bd27773 version and it performed \"as expected\". Eh, never enough tests ;)
I have looked at that commit changelog and [detailed description](http://source.git-annex.branchable.com/?p=source.git;a=blob;f=doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_4_6dff7befbaacbff573c5f72688966af5._comment;h=c636b09291a23bbce52b0367a767717137f99a21;hb=451171b7c1eaccfd0f39d4ec1d64c6964613f55a) . Not fully grasping yet why `registerurl` should not behave symmetrically with `addurl` in being sufficient by itself to add a url to content so it becomes usable for `get` right away, without some other dances like `setpresentkey`. I think I do get `rmurl` \"ambiguity\" but here on that more reflected below.
Rereading your comment [above](https://git-annex.branchable.com/bugs/registerurl_does_not_register_if_external_remote/#comment-ba9d6517d8f8c10167da95b122a022b3):
> part of it is clear: The web special remote is different from other special remotes in that content cannot be dropped from it by git-annex, and the url is the only pointer to content.
This is just an assumption on some \"special nature of web remote\", e.g. the `datalad` remote also doesn't support dropping, and URL is also just the pointer to content. And CLAIMURL functionality came IIRC exactly for that use case and before adding some kind of duality for having content accessible directly from special remote and via url.
> But if the url is claimed by another special remote, which does support dropping content, the content would still be present on it after removing its url, and would be accessible w/o using that url,
that is yet another assumption, since e.g. in the case of datalad remote `rmurl` effect would be identical to `web` remote, and there is no other way to get content from that remote. (so there is no duality mentioned above)
> All you need to do is use git-annex setpresentkey along with registerurl.
this somewhat contradicts above \"the content would still be present on it after removing its url\" which suggests that presence of URL for the remote already sufficient indication of being present on the remote.
Overall, there is seems some assumptions about URLs and external remotes which ideally should be avoided. May be it it should somehow be reflected in the external remote protocol to indicate that CLAIMing URL indicates that it is present at that URL, and that there is no other way to access that content from the remote besides via URL.
As a workaround I of cause will now either `setpresentkey` or will just reassign all urls to be handled directly by web remote somehow. But in the long run I think it is problematic design since even `registerurl` doesn't even report to which remote that URL was registered to
```
> git annex registerurl --json SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat http://www.oneukrainian.com/tmp/124.dat
{\"command\":\"registerurl\",\"error-messages\":[],\"file\":null,\"input\":[\"SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat\",\"http://www.oneukrainian.com/tmp/124.dat\"],\"success\":true}
```
so how could I generally to know proper invocation for `setpresent` key to follow it up?
"""]]

View file

@ -0,0 +1,39 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 2"
date="2023-04-05T01:03:38Z"
content="""
`registerurl`, besides modifying `.log.web` and adding URLs (with `:` prefix if being claimed by external remote), it also modifies `.log` and registers availability from web remote
```
> git annex registerurl --json SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat http://www.oneukrainian.com/tmp/124.dat
{\"command\":\"registerurl\",\"error-messages\":[],\"file\":null,\"input\":[\"SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat\",\"http://www.oneukrainian.com/tmp/124.dat\"],\"success\":true}
> git show -p git-annex
commit 22a29debc107ccdf85fb08161bdfa31f581cedeb (git-annex)
Author: Yaroslav Halchenko <debian@onerussian.com>
Date: Tue Apr 4 20:59:29 2023 -0400
update
diff --git a/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log b/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log
index dbe5653..3384a1a 100644
--- a/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log
+++ b/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log
@@ -1 +1,2 @@
+1680656369.682872384s 1 00000000-0000-0000-0000-000000000001
1680656369.621247138s 1 56425bae-be83-44d1-bb22-9f37ce9507a5
diff --git a/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log.web b/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log.web
new file mode 100644
index 0000000..022fcec
--- /dev/null
+++ b/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log.web
@@ -0,0 +1 @@
+1680656369.682162693s 1 http://www.oneukrainian.com/tmp/124.dat
```
The fact that it doesn't do that currently (but did in the past) for external remotes is currently discussed in [https://git-annex.branchable.com/bugs/registerurl_does_not_register_if_external_remote/](https://git-annex.branchable.com/bugs/registerurl_does_not_register_if_external_remote/)
So, my desire here ATM to be able to say `registerurl --remote web` and get it registered to `web` remote, thus to have web remote listed in .log and url added without `:`.
"""]]