On Mon, 18 Apr 2005, Imre Simon wrote:
>
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
