Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!emory!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!tcdcs!dce.ie!ch
From: ch@dce.ie (Charles Bryant)
Newsgroups: comp.compression
Subject: Re: Silliness in compress(1)
Message-ID: <1991Apr12.101121.9897@dce.ie>
Date: 12 Apr 91 10:11:21 GMT
References: <1991Apr10.193729.28574@agate.berkeley.edu>
Organization: Datacode Communications Ltd, Dublin, Ireland
Lines: 19

In article <1991Apr10.193729.28574@agate.berkeley.edu> greg@math.berkeley.edu writes:
>Most you of probably know that if the output of compress(1) is longer
>than the input, the program leaves the original file alone.  But has
>anyone else noticed that if the output is exactly the same length as
>the input, then compress(1) goes ahead and replaces foo with foo.Z?
>compress(1) knows not to be counterproductive, but it is perfectly
>happy to march in place.

Given that the vast majority of file systems are block based, it would
also be sensible to have an option to leave the original if no blocks
would be saved. This would be used when the compressed files were to be
left in place (instead of being archived or sent by modem). Obviously
compress(1) shouldn't guess what block size is desired, but it should be
provided as a parameter.
-- 
Charles Bryant (ch@dce.ie)
--
If you like the opinions expressed in this message, they may be available
for rent - contact your local sales office. Low interest deals available.