Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!drivax!alexande From: alexande@dri.com (Mark Alexander) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: gnudiff2.zoo compression Keywords: ZOO anti-compression Message-ID: <7M1P2N3@dri.com> Date: 6 Sep 90 16:25:28 GMT References: <1616@sixhub.UUCP> Organization: none Lines: 24 In article cybrspc!roy@cs.umn.edu (Roy M. Silvernail) writes: >I noted that PKZIP will store a file if the compressed version is no >smaller than the original. This would be a valuable addition to Zoo, >since files already compressed rarely will shrink further, and would >avoid this problem in the future. The version of ZOO I use (1.71) does have this feature. After it has written the compressed data for a single file to the ZOO file, it checks to see if it has written more bytes than are in the original file. If this is the case, it seeks back to the start of the compressed data in the ZOO file, truncates the ZOO file, then does a straight copy. This should result in a file that is the size of the original, plus a little bit for headers. I suspect that the version of ZOO that was used to create the offending file being discussed in this thread may have had a broken zootrunc() function (the system-dependent function that truncates a file). The result would be that the ZOO file contained some unused data at the end. This is especially likely if the archive contained a single file; otherwise, later files might have overwritten the unused data. Unfortunately, I didn't save a copy of this ZOO file, so I can't check my theory. -- Mark Alexander (uunet!drivax!alexande or alexande@dri.com)