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