Re: A couple of questions

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 18, 2005, 15:31 UTC
Message-ID: <Pine.LNX.4.58.0504180825280.7211@ppc970.osdl.org>
In-Reply-To: <42639F24.90007@ime.usp.br>

On Mon, 18 Apr 2005, Imre Simon wrote:

Show 8 quoted lines

>
> How will git handle a corrupted (git) file system?
> 
> For instance, what can be done if objects/xy/z{38} does not pass the
> simple consistency test, i.e. if the file's sha1 hash is not xyz{38}?
> This might be a serious problem because, in general, one cannot
> reconstruct the contents of file objects/xy/z{38} from its name
> xyz{38}.

Nothing beats backups and distribution. The distributed nature of git means that you can replicate your objects abitrarily.

> Another problem might come up if the file does pass the simple
> consistency test but the file's contents is not a valid git file,

Run "fsck-cache". It not only tests SHA1 and general object sanity, but it does full tracking of the resulting reachability and everything else. It prints out any corruption it finds (missing or bad objects), and if you use the "--unreachable" flag it will also print out objects that exist but that aren't readable from any of the HEAD nodes (which you need to specify).

So for example

	fsck-cache --unreachable $(cat .git/HEAD)

will do quite a _lot_ of verification on the tree. There are a few extra validity tests I'm going to add (make sure that tree objects are sorted properly etc), but on the whole if "fsck-cache" is happy, you do have a valid tree.

Any corrupt objects you will have to find in backups or other archives (ie you can just remove them and do an "rsync" with some other site in the hopes that somebody else has the object you have corrupted).

Of course, "valid tree" doesn't mean that it wasn't generated by some evil person, and the end result might be crap. Git is a revision tracking system, not a quality assurance system ;)

		Linus