Xref: utzoo comp.binaries.ibm.pc.d:376 comp.sys.ibm.pc:16318
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!ncar!boulder!sunybcs!bingvaxu!leah!itsgw!steinmetz!uunet!van-bc!skl
From: skl@van-bc.UUCP (Samuel Lam)
Newsgroups: comp.binaries.ibm.pc.d,comp.sys.ibm.pc
Subject: Re: Source code newsgroup for MS-DOS
Summary: Archive-testing is *just* archive-extracting with a twist.
Keywords: ARC CRC error-checking news archive
Message-ID: <1790@van-bc.UUCP>
Date: 7 Jun 88 08:38:29 GMT
References: <1785@van-bc.UUCP> <4802@dasys1.UUCP>
Followup-To: comp.sys.ibm.pc
Organization: Balliffe Consulting, Vancouver, B.C., Canada
Lines: 21

In article <4802@dasys1.UUCP>, wfp@dasys1.UUCP (William Phillips) wrote:
>In article <1785@van-bc.UUCP> skl@van-bc.UUCP (Samuel Lam) writes:
>>With the current scheme, if an ARC file got hit during transmission, there
>>is no easy way to detect this before you start unARCing, since none of those
>>CRC's are of any use until you have got the *unARCed* content of the ARCed
>>files.
>Not true.  You have the very useful option with both arc and pkxarc to
>_test_ your .arc file before you ever unarc it. ...

Did you know that testing an archive with -t (or /t, or t) are nothing
more than just *unarcing* the files in the archive and redirect the output
to the bit bucket?  (That's what the (de)archiver does internally in
response to the test-archive request.)

Therefore, testing an archive before extracting does not provide any
protection which extracting right away won't give.  And those corruptions
which drive the extracting process nuts will drive the test-archive
process nuts just the same.

-- 
Samuel Lam     {ihnp4!alberta,watmath,uw-beaver,ubc-vision}!ubc-cs!van-bc!skl