From 76721b62ddedca7d272d939853b255fe82d2cf8c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 26 Jun 2020 13:58:28 -0400 Subject: [PATCH] does not make sense to lockContent on web 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. --- doc/todo/lockContent_for_special_remotes.mdwn | 3 --- 1 file changed, 3 deletions(-) diff --git a/doc/todo/lockContent_for_special_remotes.mdwn b/doc/todo/lockContent_for_special_remotes.mdwn index 4b7d90611a..7d9b571cfa 100644 --- a/doc/todo/lockContent_for_special_remotes.mdwn +++ b/doc/todo/lockContent_for_special_remotes.mdwn @@ -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