Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!psuvax1!rutgers!topaz.rutgers.edu!linhart From: linhart@topaz.rutgers.edu (Mike Threepoint) Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d Subject: Re: compressing compressed stuff Keywords: Yale, Master... Message-ID: Date: 12 May 88 18:07:43 GMT References: <292@cullsj.UUCP> <696@fig.bbn.com> <4744@teddy.UUCP> <5198@umn-cs.cs.umn.edu> Reply-To: linhart@topaz.rutgers.edu.UUCP (Mike Threepoint) Organization: The Society for Creative Euthanasia Lines: 50 Disclaimer: If you find me in error, report to your local SCE representative. Xref: utzoo comp.sources.d:2155 comp.binaries.ibm.pc.d:291 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!psuvax1!rutgers!topaz.rutgers.edu!linhart From: linhart@topaz.rutgers.edu (Mike Threepoint) Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d Subject: Re: compressing compressed stuff Keywords: Yale, Master... Message-ID: Date: 12 May 88 18:07:43 GMT References: <292@cullsj.UUCP> <696@fig.bbn.com> <4744@teddy.UUCP> <5198@umn-cs.cs.umn.edu> Reply-To: linhart@topaz.rutgers.edu.UUCP (Mike Threepoint) Organization: The Society for Creative Euthanasia Lines: 50 Frperg-Zrffntr: Or fher gb qevax lbhe Binygvar. randy@umn-cs.UUCP (Randy Orrison) writes: -=> This whole conversation has me puzzled. Witness: -=> pkarc: If compressing a file (by any method) does not result in -=> a saving of space, it is stored verbatim in the archive. -=> zoo: putting a zoo arhive into another zoo archive results in -=> "0%" compression and the file getting only marginally larger -=> (index information?) -=> compress: compressing a compressed file (e.g. a zoo archive) -=> results only in wasting some time. A .Z file is not created. -=> (my test resulted in "-29.30% compression, file not compressed") If compress can't make any given file smaller, it won't. Really short files also fall into this category. PKARC and zoo won't either, and just store it verbatim with a index header containing file name, date/time, CRC, and other vitals. So they would both store other archives uncompressed under most circumstances (sometimes PKARC squeaks out a 2% Huffman on other ARC files). Nested ARC's occur often in large systems like BBS software, usually with a batch file to reproduce the directory structure and extract the enclosed ARC's into the appropriate directories. I wouldn't expect anyone to do this in zoo, since the directory structure can be stored much more simply. (zoo is a much better choice for these systems, but it's not the standard and PKARC compresses better.) -=> Summary: all these methods of compression DO NOT COMPRESS if the result -=> would be larger than the original. There is NO HARM in compressing a zoo -=> archive containing a pkarc of a binary file (except for the added index -=> information at each step). Exactly. (But see above parenthetic about PKARC.) -=> The ONLY problem I can see in doing this is if the news software that does -=> compression isn't smart enough to check if the result is larger than the -=> original. If it isn't smart enough, it should be. There's no excuse for -=> not checking that simple condition. As I understand it, compress is generally used, and compress checks unless -f is specified. Along those lines, though, I've seen PKARC crunch a small file at 0% savings. That's ridiculous. Just storing it uncompressed would obviously be more efficient (and faster to extract). -- "...billions and billions..." | Mike Threepoint (D-ro 3) -- not Carl Sagan | linhart@topaz.rutgers.edu "...hundreds if not thousands..." | FidoNet 1:107/513 -- Pnews | AT&T +1 (201)878-0937