Xref: utzoo comp.binaries.ibm.pc.d:1318 comp.sys.ibm.pc:21121
Path: utzoo!attcan!uunet!husc6!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!killer!wybbs!miken
From: miken@wybbs.UUCP (Michael Neuhaus)
Newsgroups: comp.binaries.ibm.pc.d,comp.sys.ibm.pc
Subject: Re: WARNING! Vicious bug in GSARC
Keywords: GSARC, Archivers, Compression, Bugs
Message-ID: <115@wybbs.UUCP>
Date: 11 Nov 88 02:37:47 GMT
References: <6627@watcgl.waterloo.edu>
Organization: Consultant's Connection, Jenison MI
Lines: 46

In article <6627@watcgl.waterloo.edu>, rmpinchback@watmum.waterloo.edu (Reid M. Pinchback) writes:
> I've found a nasty bug in GSARC.  Its the sort of bug you come up against
> accidentally when converting archives from an old archiver (PKARC) to ...

 
     I'd like to make you aware that GSARC is now PAK, to avoid infringement
of SEA's trademark on the letters ARC.

     Thanks for finding the bug in the Move command, which occurs when
moving all of the files in a directory to an existing archive in the same
directory.  You are, however, incorrect as to the nature of the bug.  You
state:

> GSARC does NOT attempt to make an archive.  It just deletes all the files
> in the current directory.
 
     PAK (formerly GSARC) does update the archive, but when it then follows
this by deleting the files, it doesn't check that the newly-updated archive
is one of those files!  Future releases will correct this, of course, but in
the meantime avoid this situation by keeping the destination archive in
another directory when Moving entire directories.  This bug won't show up
if you are Moving files to a newly created archive, but it's better to be
safe.
     It's too bad this didn't come out in the six months of beta-test.

> archives are 20%-25% LARGER than they were with ARC or PKARC.

     I'd seriously like to see your data, since everything we've seen has
usually been the reverse.  It is true that on certain rare text files between
1K and 5K in final size, Crushing is marginally larger than PKARC's
Crunching, but never more than 1%.  In a sample of 20 text files in this size
range, only 3 exhibited this characteristic:

Name       Original size  PAK Size  PKARC size  difference
EVAL2.DOC       2560        1567      1551       1.02%
SUBMIT.DOC      8704        4714      4709       0.11%
WRITE.DOC       5600        3186      3180       0.19%

      Incidently, the final sizes were 34177 for the PAK archive, and
34422 for the PKARC archive, for a net savings of 245 bytes.  Not much,
but excellent considering that PAK has the most difficulty with files in
this range.  On all other test archives, PAK averaged about 10% smaller than
PKARC, and 15% smaller than ARC.

Michael Neuhaus
NoGate Consulting