From ce8a034ecd700d9e0f72473351cc390043c50a72 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 26 Feb 2020 18:38:12 -0400 Subject: [PATCH] idea, not impementing today --- ..._2fe8b29a06bac1e004f8fa2109a27fab._comment | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 doc/bugs/gcrypt_special_remote_not_working/comment_4_2fe8b29a06bac1e004f8fa2109a27fab._comment diff --git a/doc/bugs/gcrypt_special_remote_not_working/comment_4_2fe8b29a06bac1e004f8fa2109a27fab._comment b/doc/bugs/gcrypt_special_remote_not_working/comment_4_2fe8b29a06bac1e004f8fa2109a27fab._comment new file mode 100644 index 0000000000..bac6484251 --- /dev/null +++ b/doc/bugs/gcrypt_special_remote_not_working/comment_4_2fe8b29a06bac1e004f8fa2109a27fab._comment @@ -0,0 +1,21 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2020-02-26T22:34:35Z" + content=""" +Hmm, one idea is that git-annex fsck --from remote, when the remote is +encrypted, could check if the non-encrypted key is present. If so, it +could warn loudly. + +(I don't think it could delete it safely; the user would still have to do +that. Deleting it might violate numcopies and lead to data loss. It +could move it to the local repo, but that risks fsck filling up the local +repo, and also it's not guaranteed that the local repo is a place the user +expects to continue storing data; it could even be a throwaway repo they're +going to nuke after the fsck.) + +This does make a slow fsck path even slower, which is a bit of a heavy +price to pay going forward. Although the belt-and-suspenders nature +of checking that git-annex has not forgotten to encrypt some data may be +worth it. +"""]]