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

update

Browse source
This commit is contained in:
Joey Hess 2011-03-09 15:59:44 -04:00
parent b5134b4716
commit 9229d182d3
3 changed files with 20 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
doc/future_proofing.mdwn
View file

@ -33,4 +33,5 @@ problem:
for the data that encode everything needed to match it back to the
metadata. So if a filesystem is badly corrupted and all your annexed
files end up in `lost+found`, they can easily be lifted back out into
another clone of the repository.
another clone of the repository. Even if the filenames are lost,
it's possible to [[walkthrough/recover_data_from_lost+found]].

1
doc/walkthrough.mdwn
View file

@ -23,4 +23,5 @@ A walkthrough of the basic features of git-annex.
backups
untrusted_repositories
what_to_do_when_you_lose_a_repository
recover_data_from_lost+found
"""]]

17
doc/walkthrough/recover_data_from_lost+found.mdwn Normal file
View file

@ -0,0 +1,17 @@
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
git annex add recovered-content
git rm recovered-content
git commit -m "recovered some 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. This works particularly well if the SHA1 backend is used, but even
with the default backend it will work pretty well, as long as fsck
preserved the modification time of the files.