File: day_292__dead_keys.mdwn

package info (click to toggle)
git-annex 10.20250416-2
  • links: PTS, VCS
  • area: main
  • in suites: trixie
  • size: 73,572 kB
  • sloc: haskell: 90,656; javascript: 9,103; sh: 1,469; makefile: 211; perl: 137; ansic: 44
file content (21 lines) | stat: -rw-r--r-- 1,094 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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.