On Tue, 2005-02-22 at 02:04 -0400, Peter Cordes wrote: [...] > Scanning extra files: > > > Repair is required. > 1 file(s) exist but are damaged. > 47 file(s) are ok. > You have 1982 out of 1984 data blocks available. > You have 2 recovery blocks available. > Repair is possible. > 2 recovery blocks will be used to repair. >
Ok, so far so good.. > Computing Reed Solomon matrix. > Constructing: done. > Solving: done. > > Wrote 14680064 bytes to disk > > 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. > I gather that Reed Solomon codes can sometimes require more par > blocks than normal, if the missing blocks form unlucky polynomial > coefficients or something... Maybe par2 isn't detecting that? > I suspect it's simply a bug in the way it's writing the file. If you run par2 multiple times, does the same thing happen? > > [1] My data is an episode of Mystery Science Theater 3000, which > apparently is legal to copy, see dapcentral.org :) > Sure, of course. :) [...] > > email me if you want me to do something like put these files on a web > server where you can get them. > I doubt it's something in the actual repair algorithm; if it's still damaged (finding 40 of 42 valid parts), it probably just didn't succeed in saving the new file. Does it spit out any errors while repairing? An strace log would be useful, as well; strace -f <par2repair cmd> &> log. -- Andres Salomon <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
