From b168a06b821b81078f674ae28b56697236465d4b Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Wed, 26 Jun 2019 20:38:19 +0000 Subject: [PATCH] Added a comment --- ...comment_5_37fd824cf9f2dcc59616b9d49e38c262._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/external_backends/comment_5_37fd824cf9f2dcc59616b9d49e38c262._comment diff --git a/doc/todo/external_backends/comment_5_37fd824cf9f2dcc59616b9d49e38c262._comment b/doc/todo/external_backends/comment_5_37fd824cf9f2dcc59616b9d49e38c262._comment new file mode 100644 index 0000000000..fae1136126 --- /dev/null +++ b/doc/todo/external_backends/comment_5_37fd824cf9f2dcc59616b9d49e38c262._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="comment 5" + date="2019-06-26T20:38:19Z" + content=""" +P.S. It seems that in case of missing backend implementation, the handling should revert to exactly what currently happens for WORM/URL keys? Except with a different warning message, as custom backends are _potentially_ verifiable. + +If git-annex could support [[todo/alternate_keys_for_same_content]], then for a download from an external backend key you could also compute a standard checksum-based key (e.g. MD5 or SHA256), and record its presence in the remote you got the contents from, and the correspondence to the external backend key. Then, at least, if this contents gets uploaded somewhere else, it would be verifiable even without the external backend implementation. +"""]]