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.
> 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?
Yes, the same thing happens.
before first run: part33.rar has the wrong size, and has 40/42 blocks
after: part33.rar has right size, but still only has 40/42 blocks
further runs of par2 r produce the same file (md5sum and size equal)
moving aside some of the par2 volumes (so a different set of repair blocks
will be used) results in the same failed repair, but part33 will have a
different md5 hash. Each different par2 volume results in a different md5,
but always 40/42 blocks ok. Recreating all of part33 creates a bad file too.
It's not only part33 that can't be repaired. Moving aside part04 I get
... do the repair ... verify:
Target: "MST3K___0206___20010709___Ring_of_Terror.part04.rar" - damaged. Found
1 of 42 data blocks.
Target: "MST3K___0206___20010709___Ring_of_Terror.part33.rar" - damaged. Found
40 of 42 data blocks.
Repair Failed.
Interestingly in this case, one block was successfully repaired.
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.
> [...]
> >
> > 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.
I guess I forgot to say anything to discount that obvious possibility.
I looked at the strace myself to make sure there wasn't anything
emabarrasing that I should have noticed myself...
read(5, "[EMAIL PROTECTED]"..., 131072) = 131072
write(1, "Repairing: 100.0%\r", 18) = 18
close(5) = 0
munmap(0xb6dd8000, 131072) = 0
write(3, "\315\230\275\332\364\375\266\241\f<\202\272E\v)\263\311"..., 117896)
= 117896
_llseek(3, 2841696, [2841696], SEEK_SET) = 0
write(3, "\275\2219\10_\257y\202mh\247S\376\350\374}\33\17\327]\335"...,
262144) = 262144
write(3, "\362\277i#Vnu\344xC\223h\v\245\333\354Ll] \3303\235\347"..., 131072)
= 131072
write(3, "\17\336\263S\234\356\'\267\303\307\346\222\306\23\237\245"...,
262144) = 262144
write(4, "Q\36\16\250\343W3L\370\27\214C\257\26\356\213\20\342\\"..., 116372)
= 116372
...
write(1, "Writing recovered data\rWrote 293"..., 52) = 52
write(1, "\n", 1) = 1
write(1, "Verifying repaired files:\n", 26) = 26
write(1, "\n", 1) = 1
write(4, "\262\1\217\375m\324\262r%\"[EMAIL PROTECTED]"..., 14700) = 14700
close(4) = 0
munmap(0xb7d0b000, 131072) = 0
stat64("/var/cache/tmp/mst3k/MST3K___0206___20010709___Ring_of_Terror.part04.rar",
{st_mode=S_IFREG|0664, st_size=14680064, ...}) = 0
open("/var/cache/tmp/mst3k/MST3K___0206___20010709___Ring_of_Terror.part04.rar",
O_RDONLY|O_LARGEFILE) = 4
...
So as you can see, the file was written and close(2)d with no errors. In
fact, there aren't any errors on any of the system calls. Searching for
"= -" only turns up the stat calls when it's looking for a name to rename(2)
the original to. (not counting what ld.so does at the start)
My suspicion now is that the par2 files are somehow non-standard and don't
work with this version of par2. Presumably it was with some weird piece of
software, because vol99+00.par2 is identical to the .par2, and I hope this
version of par2 wouldn't create a stupid file like that. However, running
strings on it shows: ...
5)PAR 2.0
Creator
Created by par2cmdline version 0.4.
at the end of the file.
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?
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
