Suppose something goes wrong, and fsck puts all the files in lost+found. It's actually very easy to recover from this disaster.
First, check out the git repository again. Then, in the new checkout:
$ mkdir recovered-content
$ sudo mv ../lost+found/* recovered-content
$ sudo chown you:you recovered-content
$ chmod -R u+w recovered-content
$ git annex add recovered-content
$ git reset HEAD recovered-content
$ rm -rf recovered-content
$ git annex fsck
The way that works is that when git-annex adds the same content that was in the repository before, all the old links to that content start working again. So, this works as long as you're using one of the SHA* or other checksumming backends, which is the default.
Other steps I understand but what is the purpose of the last, "git annex fsck"? Shouldn't "git annex add" recreate any missing annex files and therefore fix dangling symlinks?
git annex fsck
at the end will verify if you've managed to recover all the files.This procedure is also very useful when you accidentally rename files in the object dir.
Such a case occurred to me when I 'detoxed' a git-annex: detox renames files and it substitutes "--" with "-", thus destroying my annex.
I find git-annex very elegant in this situation: rather than trying to rename back the files (objects) you just re-add them (since content is still there unmodified) recreating the symlink targets!
Kudos!
lost+found does not contain only annexed file, right? It may contain any kind of file not originally annexed.
Examples:
In all these cases, this command will result in new additions to the annex.
This is not what a recovery should do, is it?
Shouldn't that become rather something like:
If you're worried about lost+found containing non-annexed content, you can copy (
cp
) the files, rather than moving them (mv
). After adding the files,git annex unused
will find any non-annexed ones that were added, and they can then be removed.This tip was written before
git annex reinject --known
existed, but that is also a good way to do it.