diff options
author | 2015-06-09 15:59:03 -0400 | |
---|---|---|
committer | 2015-06-09 15:59:03 -0400 | |
commit | 72983d333193a2236bbe0b8d23235933058e938b (patch) | |
tree | 6b22a381c7add604afb7e32fcf5f43a9345653dc | |
parent | 2206e698051db2f435b249a4988a6550be09a007 (diff) |
devblog
-rw-r--r-- | doc/devblog/day_292__dead_keys.mdwn | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/doc/devblog/day_292__dead_keys.mdwn b/doc/devblog/day_292__dead_keys.mdwn new file mode 100644 index 000000000..3ad66edb5 --- /dev/null +++ b/doc/devblog/day_292__dead_keys.mdwn @@ -0,0 +1,21 @@ +Ever since `git annex fsck --all` was added, people +[have](http://bugs.debian.org/753888) +[[complained|bugs/fsck_reports_unsolvable_problem]] that +there's no way to stop it complaining about keys whose content is gone for +good. Well, there is now: `git annex dead --key` can be used when you know +that a key is no longer available and want fsck to stop complaining about +it. + +Running fsck on a directory will intentionally still complain about files +in the directory with missing contents, even if the keys have been marked +dead. + +The crucial part was finding a good way to store the information; luckily +location log files are parsed in a way that lets it be added there without +breaking backwards compatability. A bonus is that adding a key's content +back to the annex will automatically bring it back from the dead. + +I'm pondering making `git annex drop --force` automatically mark a key as +dead when the last copy is dropped, but I don't know if it's too DWIM or +worth the complication. Another approach would be to let fsck mark keys as +dead, but that would certianly need an extra flag. |