From 26673cf045528e6cee80f2fef7ffd4eebca42f6c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 13 Nov 2015 13:47:14 -0400 Subject: comment --- ...ent_1_be530543f32133a96640e3e82a1bc241._comment | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/bugs/detox___34__destroys__34___annex/comment_1_be530543f32133a96640e3e82a1bc241._comment diff --git a/doc/bugs/detox___34__destroys__34___annex/comment_1_be530543f32133a96640e3e82a1bc241._comment b/doc/bugs/detox___34__destroys__34___annex/comment_1_be530543f32133a96640e3e82a1bc241._comment new file mode 100644 index 000000000..bfd7c28f0 --- /dev/null +++ b/doc/bugs/detox___34__destroys__34___annex/comment_1_be530543f32133a96640e3e82a1bc241._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-11-13T17:36:29Z" + content=""" +git-annex tries to prevent this kind of thing by removing the write bit +from the the object storage directories. But I suppose that doesn't prevent +those directories from being renamed themselves (or from it turning on the +write bit to rename files inside them, if it goes so far). + +In the end, git-annex just can't help you if you feed your drive into a +indiscriminate shredder. Except helping you have a copy of the data in a +repository elsewhere. So I don't see how this is a bug in git-annex. + +But surely it's a massive bug in detox if it does anything inside .git or any +VCS directory? + +Anyway, the result after running this thing is similar to fsck having put +all your annexed objects in lost+found with useless names. I'd recover the +same way, by moving the annexed objects from .git/annex/objects into the +repository, and running git-annex add on them, so it will pick the same +hashes as before and will move the objects back into place. +See [[recover_data_from_lost+found]]. +"""]] -- cgit v1.2.3