From owner-freebsd-hackers Fri Dec 30 19:29:14 1994 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA10185 for hackers-outgoing; Fri, 30 Dec 1994 19:29:14 -0800 Received: from wcarchive.cdrom.com (wcarchive.cdrom.com [192.216.191.11]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA10177 for ; Fri, 30 Dec 1994 19:29:10 -0800 Received: from reggae.ncren.net (reggae.ncren.net [128.109.131.3]) by wcarchive.cdrom.com (8.6.8/8.6.6) with ESMTP id TAA29477 for ; Fri, 30 Dec 1994 19:29:01 -0800 Received: from ponds.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA01496; Fri, 30 Dec 94 22:28:37 -0500 Received: (rivers@localhost) by ponds.UUCP (8.6.9/8.6.5) id WAA03568; Fri, 30 Dec 1994 22:02:51 -0500 Date: Fri, 30 Dec 1994 22:02:51 -0500 From: Thomas David Rivers Message-Id: <199412310302.WAA03568@ponds.UUCP> To: freebsd-hackers@wcarchive.cdrom.com, freebsd-bugs@freebsd.org, rivers@ncren.net, biljir%squink@ncren.net Subject: Pretty serious bug in compress(1). Sender: hackers-owner@freebsd.org Precedence: bulk A down-feed news site of mine complained after my upgrade to 2.0R that some of his news batches were being botched instead of batched. I took a quick look at things to discover that the compress(1) program had been broken in the move from 1.1.5 to 2.0, but probably not in a way that anyone else would notice. In particular, this site can't handle 16-bit compression, so I use '-b 12' on the news feed. But, compress(1) was using a magic number in the file (will zwrite was in it's cookie) that indicated it was a 16-bit compressed file. You can demonstrate this problem by using the following: cd /tmp cp /etc/passwd /tmp compress -b 12 passwd file passwd.Z the output of the file command will indicate this is a 16-bit compressed file, when, in fact, it is a 12-bit compressed file. When uncompress/compress -d gets this file, it begins to apply 16-bit tables to the input, and sometimes fails in the middle, producing junk. Although, it won't do it with every input (because of the LZW hash lengths, etc...) it's not too hard to stumble on some where the uncompression fails. The following diff to zopen.c in /usr/src/usr.bin/compress will correct the problem. Also, someone may want to check on the zopen/zwrite() routines now in libc.a. *** zopen.c.ori Fri May 27 08:30:59 1994 --- zopen.c Sat Dec 31 11:05:29 1994 *************** *** 258,264 **** if (fwrite(magic_header, sizeof(char), sizeof(magic_header), fp) != sizeof(magic_header)) return (-1); ! tmp = (u_char)(BITS | block_compress); if (fwrite(&tmp, sizeof(char), sizeof(tmp), fp) != sizeof(tmp)) return (-1); --- 258,264 ---- if (fwrite(magic_header, sizeof(char), sizeof(magic_header), fp) != sizeof(magic_header)) return (-1); ! tmp = (u_char)((maxbits) | block_compress); if (fwrite(&tmp, sizeof(char), sizeof(tmp), fp) != sizeof(tmp)) return (-1); Hopefully, this can make it into 2.1... - Dave Rivers -