Alex Malinovich wrote:
On Mon, 2005-12-12 at 18:51 -0800, Steve Lamb wrote:
Alex Malinovich wrote:
--snip--
I've refrained from joining in, so far, but I just can't
resist :-)
I don't know, maybe I'm just dense or something, but explain to me why
you would WANT to put that information in the archive itself?
What, the checksums? Uh, so the reference is where you need it, with the
archive. No need to go external. Also since the checksums are on a
per-file-inside-the-archive basis you can see what files are corrupt and
extract around that. Something tar, esp. split tars, is utterly incapable of.
Trust me, I tried.
This is all assuming that the portion of the file that got corrupted
ISN'T the portion storing the checksum data. If it is, the file is of no
use to you.
This is not quite true. Usually, with a disc file or a file transmitted
over a link of some sort, a block of bytes gets corrupted, usually with
a size on the order of 1KB. If an archive is much larger than 1KB (the
usual case, in my experience) then most of the archive may actuallly
be usable. If each file contained in the archive has a separate
redundancy check, then one may be able (in my experience, usually can)
do a partial recovery, and extract some of the information. In one case,
I had backups which got corrupted (due to a virus overwriting sectors
on floppy discs). I had the same file corrupted in different places,
and was able to recover the entire archive (it was a PKZIPped archive)
by doing partial recovery on two different backups of the same archive.
If an archive is CORRUPTED (which is why we're distributing the sums and the
PARs in the first place), what good will it be that the sums and
recovery info are IN the file?
Why do you suppose we put cyclic redundancy checks into messages
used in various protocols, like FTP, TCP, IP, MTP, etc? By your
reasoning, ISTM, you would view such cyclic redundancy checks to
be invalid. They should be sent via a separate message. But then
what checks the separate messages? Or in your case, what checks
the separate files? How do you know your separate files containing
the redundancy checks aren't corrupt? Do you have another set of
files checking the check files? And what checks the check check files?
To put it another way, are you aware that hard discs have redundancy
in them to allow one to recover corrupted sectors? By your reasoning,
this could not be put on the same disc, it would have to be on
another disc.
Partial recoveries in spite of the above. IE, redundancy is a good thing.
Say the part of the archive that is corrupt is a file that isn't needed. You
don't have to wast an entire PAR on that section. Just extract the other
files and ignore the corrupted one.
[snip]
I'm very familiar with the RAR program and its evolution over the last
10+ years, including the new features that 3.0 introduced. My question,
as before, remains what practical benefit this software presents that
CANNOT be achieved otherwise?
I can think of two practical benefits which RAR provides, and
which no other software can provide:
(1) the ability to open and extract files from previously created RAR
format archives, and (2) the exchange of files with people who as a
customary practice use that format for archiving and compression
and prefer to send and receive them in that format.
I can't control my neighbor's dog, let alone my neighbor. If
someone I am doing a contract for requests RAR format, then
that's what he'll get, and I won't argue. I consider putting
food on my table a very practical thing.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
