From 9eb26116e50bac830b0d944935fc471a5e501449 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 9 Jun 2015 13:24:44 -0400 Subject: full design --- ...ent_2_d32d4cd471632f63db681f3495039b00._comment | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment (limited to 'doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment') diff --git a/doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment b/doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment new file mode 100644 index 000000000..2a08e3e2b --- /dev/null +++ b/doc/bugs/fsck_reports_unsolvable_problem/comment_2_d32d4cd471632f63db681f3495039b00._comment @@ -0,0 +1,51 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2015-06-09T16:59:22Z" + content=""" +Had a closer look at using a transition for this. It would mean that, when +merging with any repo that has not made the transition yet, that repo would +need to be modified to remove log files for keys that are no longer present +anywhere. Without a list of exactly which keys, the transition could take +out files, as it spreads, that were not the ones originally desired to be +ignored. + +So, I think that and the branch rewriting overhead of transitions both make +a transition not a desirable way to handle this. + +Seems like the best way, then, is a log file where keys can be listed that +are known gone and that fsck should shut up about. Although there could be +scalability problems to listing them all in a single file, which would all +need to be loaded into memory by fack. + +Or, could have separate files per key, but that adds another query to every +key fsck processes. + +Or, the location log format could be extended, to add a flag to indicate +when fsck should ignore a given key. This adds some complexity to file +formats, but it seems like the best choice. + +Could extend the 1/0 in the log to add a third value for "ignore this". +Turns out that putting eg 'X' there doesn't break any old versions of +git-annex; they ignore the unparsable line, and the result is the same as a +'0' line; the key is not present in the specified location. + +So, if there's an 'X', it means the key is thought to be dead; it's not +present in that location, and fsck should ignore when its content is +entirely missing. + +It would, probably, also make sense for fsck to detect when a key has +location indication for both dead and present, and convert the +'X' to an '0', since the content has stopped being entirely missing. +(Eg, when a previously unknown remote that has the content becomes available.) + +As to the UI for this, it could be added to `git annex forget` or a new +command. It would also be possible for `drop --force` to automatically set +the dead flag when it removed the last copy of a key. Seems like, if the +user has requested a forced drop of the lat copy, they don't need fsck +telling them about it later. + +I think that only fsck --all (or in a bare repo) should ignore dead keys +though. If a git work tree has files that point to dead keys, fsck should +still complain. +"""]] -- cgit v1.2.3