From c39d72ac78f1628309affb18c522ad15556a66f9 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 5 Apr 2023 15:00:39 -0400 Subject: [PATCH] comments --- ..._4f2c98add8a4f7b9f49e54e12fd79f10._comment | 64 +++++++++++++++++++ ..._b9057ce47bb57b3a3dbe390672310898._comment | 16 +++++ ..._70244d4f7f81b6799cd541ad14b38ee0._comment | 14 ++++ 3 files changed, 94 insertions(+) create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_4_4f2c98add8a4f7b9f49e54e12fd79f10._comment create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_5_b9057ce47bb57b3a3dbe390672310898._comment create mode 100644 doc/todo/registerurl_--remote_REMOTE/comment_3_70244d4f7f81b6799cd541ad14b38ee0._comment diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_4_4f2c98add8a4f7b9f49e54e12fd79f10._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_4_4f2c98add8a4f7b9f49e54e12fd79f10._comment new file mode 100644 index 0000000000..6ef9e536ef --- /dev/null +++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_4_4f2c98add8a4f7b9f49e54e12fd79f10._comment @@ -0,0 +1,64 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2023-04-05T17:25:48Z" + content=""" +Whups, I forgot about the newish unregisterurl! That's the true inverse of +registerurl. So rmurl is really more the inverse of addurl. + +I think I've fully understood the situation that led to this reversion now. +I do think it was a reversion. That change was all about SETURLPRESENT and +SETURLMISSING in the external special remote protocol, as well as rmurl; +I think that the effect on registerurl was not considered. + +So while I'd like to simplify registerurl to as basic a plumbing command as +possible, and would prefer it not to update location tracking, there's the +matter of backward compatability. Especially for simple cases like adding +regular web urls with it. It would be ok to change it back to update location +tracking for remotes that claim an url. As long as unregisterurl can be +symmetric with it --- can it? + +rmurl also has its own wacky behavior in this area: + + # git-annex addurl --fast https://cdimage.debian.org/debian-cd/current/i386/bt-cd/debian-11.6.0-i386-netinst.iso.torrent + (downloading torrent file...) addurl https://cdimage.debian.org/debian-cd/current/i386/bt-cd/debian-11.6.0-i386-netinst.iso.torrent (from bittorrent) (to debian-11.6.0-i386-netinst.iso) ok + (recording state in git...) + # git-annex rmurl debian-11.6.0-i386-netinst.iso https://cdimage.debian.org/debian-cd/current/i386/bt-cd/debian-11.6.0-i386-netinst.iso.torrent + rmurl debian-11.6.0-i386-netinst.iso ok + (recording state in git...) + # git-annex whereis debian-11.6.0-i386-netinst.iso + whereis debian-11.6.0-i386-netinst.iso (1 copy) + 00000000-0000-0000-0000-000000000002 -- bittorrent + ok + # git-annex get debian-11.6.0-i386-netinst.iso + (fails) + +Is that a bug? It's certianly not ideal for the bittorrent special +remote, which can't download the file once the url is removed. (It is +documented behavior though.) + +While thinking about those questions, I thought of this situation: + + # git-annex initremote s3 type=S3 .. + # git-annex copy --key $key --to s3 + # git-annex registerurl $key $url + # git-annex unregisterurl $key $url + # git-annex drop --key $key --from s3 + +At the end there, it's still able to drop the content from s3. + +Now, consider hypothetically, if I decide to make the S3 remote CLAIMURL +urls that are in the S3 bucket. As things stand, that won't change the +above scenario. (Although the key won't be recorded as located in the web +after registerurl.) + +But... If unregisterurl is changed to update remote tracking for other remotes +than web, after the S3 CLAIMURL change, the behavior of that scenario will not +be the same! After unregisterurl, it will no longer consider the content to be +present in S3. Now you're racking up S3 charges with content that git-annex +stored in S3, but that it refuses to delete. That seems bad. + +So, that scenario is leading me to think that I should not change +unregisterurl (or rmurl) to update location tracking of remotes other than web. +And so changing registerurl is also looking like a bad idea. +"""]] diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_5_b9057ce47bb57b3a3dbe390672310898._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_5_b9057ce47bb57b3a3dbe390672310898._comment new file mode 100644 index 0000000000..3a4aaeebe0 --- /dev/null +++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_5_b9057ce47bb57b3a3dbe390672310898._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 5""" + date="2023-04-05T18:47:51Z" + content=""" +What I'm inclined to do is is add a --remote= parameter to registerurl and +unregisterurl. If the specified remote does not claim the url, have it fail +to add it. (See also [[todo/registerurl_--remote_REMOTE]]) + +So, you can then use registerurl with --remote=$uuid, check that it +succeeded, and then use setpresentkey to mark it present on that uuid. +Without the fragility you complained of. + +(Could registerurl with --remote update location tracking itself? Maybe, +but I'd worry about a scenario like in the previous comment.) +"""]] diff --git a/doc/todo/registerurl_--remote_REMOTE/comment_3_70244d4f7f81b6799cd541ad14b38ee0._comment b/doc/todo/registerurl_--remote_REMOTE/comment_3_70244d4f7f81b6799cd541ad14b38ee0._comment new file mode 100644 index 0000000000..7c0d396031 --- /dev/null +++ b/doc/todo/registerurl_--remote_REMOTE/comment_3_70244d4f7f81b6799cd541ad14b38ee0._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2023-04-05T17:46:54Z" + content=""" +What it could do is with --remote=foo, check if foo claims the url. If not, +fail to register the url. The discussion in +[[bugs/registerurl_does_not_register_if_external_remote]] +is inclining me toward an option that works like that. + +I suppose that --remote=web could, as a special case, force use of the web +special remote, bypassing any CLAIMURL. `addurl --raw` does the same thing, +but it makes sense to have a plumbing level way to do that. +"""]] -- 2.30.2