Xref: utzoo unix-pc.general:3581 comp.sys.att:7324
Path: utzoo!attcan!utgpu!watmath!uunet!tut.cis.ohio-state.edu!att!shuxd!attdso!rolls!argon!ebh
From: ebh@argon.UUCP (Ed Horch)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: uncompress and enhanced diagnostics
Message-ID: <778@argon.UUCP>
Date: 15 Aug 89 19:14:40 GMT
References: <486@manta.pha.pa.us> <19997@cup.portal.com> <785@bagend.UUCP> <8991@cbnews.ATT.COM>
Reply-To: ebh@argon.UUCP (Ed Horch)
Organization: Lightspace Designs, Highland Park, NJ
Lines: 23

In article <8991@cbnews.ATT.COM> res@cbnews.ATT.COM (Robert E. Stampfli) writes:
>In article <785@bagend.UUCP> someone writes:
>>[about trying to uncompress the new s4diag file and having it grow
>>until ulimit is hit or the file system runs out of space, or something
>>equally antisocial]
>
>I have heard several people allude to compress doing this to them, and I
>frankly lay no claims as to knowing why.

The most common cause of this is transferring a compressed file
without setting your file transfer type to "binary" in whatever file
transfer program you're using, e.g. Kermit or FTP, when said file
transfer program defaults to seven-bit text.  The result is a
corrupted file, since the high bit of each byte is stripped off.  This
confuses compress's idea of what compressed bit patterns map to what
plaintext strings.

If you're not sure whether what you've got is clean or not, zcat the
file and pipe it through "od -c".  If the output looks like garbage,
it probably is.  GIGO.  (Using "od -c" is a safe way of catting a file
that might contain unknown control sequences.)

-Ed