mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

does not make sense to lockContent on web

Browse source 
Looked into this, and dropKey from web actually removes the url,
so git-annex won't try to get content from it.

So, if lockContent were implemented for web, and the web was left as the
only thing containing an object, another repo could at the same time
drop from web and remove its url, leaving no way to get the object.

Add to that, of course, the web is typically set untrusted, and so
implementing lockContent would not then be useful.

Similar reasoning applies to the bittorrent special remote, as well
as the fact that it does not even implement checkKey.
This commit is contained in:
Joey Hess 2020-06-26 13:58:28 -04:00
parent b316a85ede
commit 76721b62dd
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 0 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
doc/todo/lockContent_for_special_remotes.mdwn
View file

@ -4,9 +4,6 @@ special remotes can lock content though:
* bup and git-lfs and tahoe can't drop content, so content is implicitly locked
* S3 has an object lock feature, I don't know if it would be usable for
this, but woth investigating.
* web can't drop content, so content is also implicitly locked there
(of course web is often untrusted so git-annex won't count it as a copy
anyway then)
* adb could use some shell trick perhaps
* It might be possible for an external remote to lock content, but it would
be a tricky extension to the protocol, since lockContent needs to keep it