update

doc/future_proofing.mdwn

@@ -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]].

doc/walkthrough.mdwn

@@ -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
 """]]

doc/walkthrough/recover_data_from_lost+found.mdwn

@@ -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.