mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Browse source
This commit is contained in:
https://launchpad.net/~barthelemy 2018-11-15 02:00:18 +00:00 • committed by admin
parent 827d9c3135
commit ea3d399789
1 changed files with 43 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

43
doc/forum/got_confused_by_fsck.mdwn Normal file
View file

@ -0,0 +1,43 @@
Hello,
in a clean-up spree, I removed unused content from my repos and ran fsck.
I found the behaviour of fsck surprising. I'm reporting it here to give feedback (and maybe get corrected).
I expected fsck to basically check that git annex's "recorded state" matches the actual
filesystem state (ie. expected files are present and they have the expected checksum).
fsck does that, but it also checks that the "numcopies" rule is enforced.
If I'm not mistaken, this check is quite different:
* it does not correspond to an error
* the reported issue is possibly irrelevant if the repo has an outdated view of the other remotes.
* the reported issue might be fixed by adding copies of the content to any other repo, not specificallyb to the one being fsck-ed.
Moreover, if fsck checks numcopies, I'd expect it to also check if the "required"
rule is enforced on the current repo, which it does not (tested on git annex 6.20170101.1).
Sice fixing a missing "required" file would need to add a copy to current repo, I'd consider this check more "local" than the numcopies one.
(Or alternatively, maybe fsck sould fully be "global" and report "required" rule violations about all the repos/remotes?).
Because my backup/archival repos are bare, fsck defaults to --all, and will complain
about insufficient numcopies for content that I intentionally dropped (with --unused --force).
It scared me at first, but I not
I envision several solutions to avoid those complaints:
* use --numcopies=0 (by the way, https://git-annex.branchable.com/git-annex-fsck/, states
"To verify data integrity only while disregarding required number of copies, use --numcopies=1.",
I think it should be =0)
* mark all those keys as dead (this seems time consuming)
* rewrite the git history or use git annex forget (untested, seems dangerous).
* maybe replace my backup/archival bare git repos with "directory" special remotes (less state involved).
Am I missing a better way?
PS. I attached a script illustrating the issue, together with its output.
PPS Thank you for git-annex!