On Wed, 2005-02-23 at 16:13 -0400, Peter Cordes wrote: > On Tue, Feb 22, 2005 at 10:57:16PM -0500, Andres Salomon wrote: > > On Tue, 2005-02-22 at 02:04 -0400, Peter Cordes wrote: > > >... > > > Verifying repaired files: > > > > > > Target: "MST3K___0206___20010709___Ring_of_Terror.part33.rar" - > > > damaged. Found 40 of 42 data blocks. > > > Repair Failed. > > > > Hrm. Did it create any additional files? IIRC, it should move the old > > part33.rar to part33.rar.1, and repair part33.rar. > > Yeah, that happens. I guess I should have said so in my first mail, but I > consider myself an experienced par2 user; I've made heavy use of par2 in the > last month downloading stuff from usenet and adding redundancy to DVDs I burn. > I've been using par2 to successfully repair other files on this computer; > I'm sure it's something about this data, not par2 or my setup.
Ok. I think we should probably take this upstream; would you mind doing that, since you clearly know how to debug this? [...] > > Running par2 on a different machine (an Athlon running Linux 2.6.7) in a > symlinks farm to a read-only NFS mount of the data to be repaired results in > exactly the same repair (same md5), with 40/42 blocks ok. > Right, it definitely doesn't sound like the sort of thing that's specific to your computer/hardware... [...] > > Are there bad implementations of par2 out there, or can bad RAM in > someone's computer create a bad set of par files that have consistent > checksums? > Offhand, I don't know. I wouldn't think that would be the case, but.. Who knows. It definitely sounds like a pretty serious bug, somewhere in par2.. -- Andres Salomon <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
