From: Imre Simon <is@ime.usp.br>
To: git <git@vger.kernel.org>
Subject: A couple of questions
Date: Mon, 18 Apr 2005 08:51:00 -0300 [thread overview]
Message-ID: <42639F24.90007@ime.usp.br> (raw)
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}.
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,
i.e. something that
(*) successfully inflates to a stream of bytes that forms a sequence of
<ascii tag without space> + <space> + <ascii decimal size> +
<byte\0> + <binary object data>.
Are there enough internal redundancies in git to allow fixing at least
some corrupted file systems? Shouldn't there be some?
Another related observation is that git is not really based on a 160 bit
hashing scheme. Indeed, only files that satisfy the above condition
(*) are allowed and this most certainly reduces the valid range of the
hashing function. I do not think that this will be a problem, but it
doesn't hurt to point this out once.
Cheers,
Imre Simon
next reply other threads:[~2005-04-18 11:45 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-18 11:51 Imre Simon [this message]
2005-04-18 15:31 ` A couple of questions Linus Torvalds
2005-04-18 16:23 ` Paul Jackson
-- strict thread matches above, loose matches on Subject: below --
2010-05-27 13:39 Paul Millar
2010-05-27 14:56 ` Hubert Kario
2010-05-31 17:59 ` Paul Millar
2010-06-02 16:19 ` Hubert Kario
2010-05-27 16:00 ` Chris Mason
2010-05-31 18:06 ` Paul Millar
2010-05-31 20:33 ` Mike Fedyk
2010-06-02 11:56 ` Paul Millar
2010-06-01 13:39 ` Martin K. Petersen
2010-06-02 13:40 ` Paul Millar
2010-06-04 1:17 ` Martin K. Petersen
2002-05-17 15:27 Steve Pratt
2002-05-17 13:11 berthiaume_wayne
2002-05-17 16:03 ` Kuba Ober
2002-05-16 18:48 Steve Pratt
2002-05-16 18:44 Steve Pratt
2002-05-16 18:55 ` Oleg Drokin
2002-05-16 20:33 ` Hans Reiser
2002-05-16 21:23 ` Kuba Ober
2002-05-16 21:44 ` Lehmann
2002-05-16 23:57 ` Hans Reiser
2002-05-17 0:45 ` Philipp Gühring
2002-05-17 1:06 ` Manuel Krause
2002-05-17 15:21 ` Kuba Ober
2002-05-17 0:17 ` Manuel Krause
2002-05-17 15:04 ` Kuba Ober
2002-05-18 20:40 ` Hans Reiser
2002-05-17 15:05 ` Kuba Ober
2002-05-16 21:44 ` Lehmann
2002-05-17 13:10 ` Valdis.Kletnieks
2002-05-17 15:35 ` Kuba Ober
2002-05-16 15:11 Steve Pratt
2002-05-16 15:35 ` Oleg Drokin
2002-05-16 14:52 Steve Pratt
2002-05-16 15:13 ` Hans Reiser
2002-05-15 21:22 Steve Pratt
2002-05-16 5:20 ` Oleg Drokin
2002-05-16 9:42 ` Hans Reiser
2002-05-16 11:40 ` Oleg Drokin
2002-05-16 11:54 ` Hans Reiser
2001-10-10 11:28 Adil EL YOUSSEFI
2001-10-10 12:11 ` David Woodhouse
1999-03-02 13:11 Neil Booth
1999-03-15 18:58 ` Stephen C. Tweedie
1999-03-15 22:46 ` neil
1999-03-16 12:22 ` Stephen C. Tweedie
1999-03-16 2:11 ` Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42639F24.90007@ime.usp.br \
--to=is@ime.usp.br \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.