From 8c777cb36dae1f1250f97db8ca395cb5ff630db5 Mon Sep 17 00:00:00 2001 From: "david.j.buckmaster@984ff2704feacab53415ac5647206517d18f88f8" Date: Sun, 24 Feb 2019 06:43:34 +0000 Subject: [PATCH] removed --- ..._6ed0b157c18487b3bda365efa92b3c0e._comment | 69 ------------------- 1 file changed, 69 deletions(-) delete mode 100644 doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_2_6ed0b157c18487b3bda365efa92b3c0e._comment diff --git a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_2_6ed0b157c18487b3bda365efa92b3c0e._comment b/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_2_6ed0b157c18487b3bda365efa92b3c0e._comment deleted file mode 100644 index 52a06189bc..0000000000 --- a/doc/bugs/data_loss_from_dedup_when_v7_unlocked_file_is_duplicated__47__truncated/comment_2_6ed0b157c18487b3bda365efa92b3c0e._comment +++ /dev/null @@ -1,69 +0,0 @@ -[[!comment format=mdwn - username="david.j.buckmaster@984ff2704feacab53415ac5647206517d18f88f8" - nickname="david.j.buckmaster" - avatar="http://cdn.libravatar.org/avatar/1650cdf23a0999fd0e03650e20c90ee7" - subject="comment 2" - date="2019-02-24T06:41:01Z" - content=""" -In case this is NOT a bug but rather an incompatibility between borg/git-annex, the bash snippet below seems to sidestep the issue if run AFTER a borg operation but BEFORE any other annex commit/sync. Unsure if I'm the only person in the world that wants a not-append-only borg repository in an unlocked+thin git-annex...but...after a borg operation that truncates+deletes files, the function uses the status printout to identify all missing, borg-controlled files, and for each - -1. Reverts the deletion (git checkout -- ..) -2. Checks if the restored file is a (dead) file pointer (file contents start with /annex/objects). If no, redo the delete and continue loop; if yes, truncate (but do not delete) the file and stage a commit. - -Truncations are then committed to force annex to see that contents have changed, and all deletions are repeated. After that, git annex add-ing a new file with old content restores the annex content that borg truncated, rather than ending up with a pointer file and missing contents. - - -Test case: - - set -x && \ - mkdir tmp && cd tmp && \ - git init && \ - git-annex init --version 7 base && \ - git-annex config --set annex.thin true && \ - \ - echo \"bar\">foo && cat foo && git-annex add foo && ls -l && git-annex sync && git-annex unlock foo && git-annex sync && \ - echo \"barbar\">foo && cat foo && rm foo && \ - \ - git checkout -- foo && truncate -s 0 foo && git add foo && git-annex sync && \ - rm foo && git-annex sync && \ - \ - echo \"bar\">ffoo && cat ffoo && git-annex add ffoo && git-annex sync && cat ffoo - - -Bash function: - - handleborgdeletes() { - echo \"(handleborgdeletes\" - - PTRFILES=() - HAVETRUNCS= - - while IFS= read -r -d '' line; do - IFS=\" \" f=( $line ) - if [ \"${f[0]}\" != \"D\" ]; then #skip non-deletes - continue - fi - - $GIT checkout -- \"${f[1]}\" #restore - if [ -n \"$(grep -F --text '/annex/objects' ${f[1]})\" ]; then #is broken annex pointer file - echo \"${f[1]} is a pointer file\" - HAVETRUNCS=1 - truncate -s 0 \"${f[1]}\" #truncate - PTRFILES+=(\"${f[1]}\") #track - $GIT add \"${f[1]}\" #stage content change - else - echo \"${f[1]} is not a pointer file\" - rm \"${f[1]}\" - fi - done < <($GIT status --porcelain=1 -z) #status in null-delimited machine readable format - - if [ -n \"$HAVETRUNCS\" ]; then - $GIT commit -m \"truncating borg deletions\" #commit content changes - - for f in ${PTRFILES[@]}; do - rm \"$f\" #repeat delete to be committed later - done - fi - echo \"handleborgdeletes)\" - } -"""]]