davison@drivax.DRI (Wayne Davison) (03/15/89)
In article <129.241A07B5@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >- If an illegal filename greater than 8 characters in length is > specified to PKZIP... I certainly hope that this doesn't mean that the PKZIP archive definition is locked into filenames of 8 characters, filetypes of 3 characters and exactly one period. There are other computers out here that have a much more general definition of a filename and I'd hate to use some future port of PKZIP if it did not allow more flexibility in the filename than ARC does. Personally, I'd prefer to see zoo enhanced to use a more efficient algorithm rather than adopting a new archiver package. I am not sure if this would be something that Rahul would enjoy doing to zoo, though, since it is currently free of multiple compressions and incompatibilities with older versions. -- Wayne Davison ...amdahl!drivax!davison
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/15/89)
In article <4397@drivax.DRI> davison@drivax.UUCP (Wayne Davison) writes: >Personally, I'd prefer to see zoo enhanced to use a more efficient algorithm >rather than adopting a new archiver package. I am not sure if this would be >something that Rahul would enjoy doing to zoo, though, since it is currently >free of multiple compressions and incompatibilities with older versions. The line count in the zoo source code is as follows: compression/uncompression code: 615 lines all other source files: 9248 lines This means that the compression/uncompression that zoo does is but a tiny fraction of everything. Thus it's tempting to add new compression code. But remembering the confusion that squashing caused, I'm very reluctant to do it. However, if a new compression algorithm were added, and the archive extension changed to something else, the new zoo would retain upward compatibility without confusing users. I would rather beat pkzip by another 5% than rush to imitate it. Does anybody have any compression technique ideas to do this? -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
malpass@vlsi.ll.mit.edu (Don Malpass) (03/16/89)
In article <6128@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >...Thus it's tempting to add new compression code. But remembering the >confusion that squashing caused, I'm very reluctant to do it. >However, if a new compression algorithm were added, and the archive >extension changed to something else, the new zoo would retain upward >compatibility without confusing users. ARE YOU LISTENING WORLD? Rahul in three short sentences has summarized the gigabytes of drivel contributed to the arc-wars. >>> ARCHIVE EXTENSION CHANGED TO SOMETHING ELSE. <<< Let's not EVER repeat PK's compatibility mistake. There's been too much blood and suffering. -- Don Malpass [malpass@LL-vlsi.arpa], [malpass@gandalf.ll.mit.edu] Have you noticed how little difference there often seems to be between ARTIFICIAL INTELLIGENCE and REAL STUPIDITY?
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/17/89)
In article <287@vlsi.ll.mit.edu> malpass@ll-vlsi.arpa.UUCP (Don Malpass) writes: | ARE YOU LISTENING WORLD? Rahul in three short sentences has summarized | the gigabytes of drivel contributed to the arc-wars. | >>> ARCHIVE EXTENSION CHANGED TO SOMETHING ELSE. <<< | Let's not EVER repeat PK's compatibility mistake. There's been too much | blood and suffering. Let's all hear it for GSARC! Creates arc files which even PKXARC can't handle. So the user downloads them, tries to unarc, thinks the download was bad, tries again... then decides I have a corrupt file on the BBS and tells everyone about it. Enough, I'm changing GSARC files to .GSA, and anything which isn't a GSARC utility gets put in ARC or ZOO format. ================================================================ [5mNew mailing address[0m: wedu@crd.ge.com We are no longer ge-crd.arpa and mail will stop working to that address in the *very* near future. Note: flames and hate mail may still use the old address ;-{ ================================================================ We now return you to our regularly scheduled signature... -- bill davidsen (wedu@crd.GE.COM) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
NU013809@NDSUVM1.BITNET (Greg Wettstein) (03/20/89)
I've noticed the following behavior in PKZIP and I was wondering if this is
actually mis-behavior or misinterpretation of the documentation on my part.
My desire is to archive the current contents of a sub-directory and store the
pathname information so that a sub-directory may be re-created as an extension
of the current directory at another time. The sub-directory which is to be
stored contains only files no lower level sub-directorys are present. To
store the subdirectory I invoked PKZIP with the following command:
PKZIP -ap testdir util
PKZIP responded an error message stating that it had nothing to do. I modified
the command to the following form even though there were not sub-diretories to
recurse to:
PKZIP -apr testdir util
Again PKZIP responded with a message stating that it had nothing to do. I then
modified the command to the following form:
PKZIP -apr testdir util:*.*
This invocation caused the program to archive all the files in the util
sub-directory but did not store any pathname information to be assoicated with
these files. I verified this by deleting the util sub-directory and then tried
to re-create the sub-directory with the following command:
PKUNZIP -xd testdir
This invocation caused all the files to be extracted to the current (root)
directory without creation of the util sub-directory.
I then used the following command to create a ZOO archive of the correct
form:
stuff util | zoo aPI testdir
All the files in the util sub-directory were stored with filenames of the
form: .:util:xxxxxxxx.xxx
I am using Version 0.92 of both PKZIP and PKUNZIP. I would be interested
in determing if this is a bug (feature?) or a misunderstanding of the
directory recursing features of PKZIP? Either e-mail or followups to the
net would be acceptable. Thanks in advance for any information which
is extended.
As always,
G.W. Wettstein
BITNET: NU013809@NDSUVM1
#! rnews