On Wed, 27 Aug 2008, Shawn O. Pearce wrote: > When we are processing a thin pack and making it non-thin we need > to update the header with a new object count. That causes us to > recompute the footer checksum for the entire pack, and the only > way to do that is to re-read the data from disk. > > If there was filesystem corruption in the process (e.g. a bad > disk sector, or a kernel bug) we don't want to produce a valid > pack at the end. Instead we need to fail-fast with the error > so the user is aware of the corruption. > > We now keep track of where the end of the original data is and > run two SHA-1 computations during the header-footer fixup. If > the original data region doesn't match the original footer we > got over the network we know there was corruption and we just > cannot trust this pack file. > > Signed-off-by: Shawn O. Pearce <spearce@xxxxxxxxxxx> > --- > > This was inspired by the data corruption thread started > by J. Bruce Fields. At some point in the thread Linus > pointed out the C Git index-pack isn't as safe as it can > be, and offered a strategy to fix it. I thought it was Nicolas Pitre who offered that strategy? Maybe I was mistaken. ;-) Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
