greg@garnet.berkeley.edu (Greg Kuperberg) (04/11/91)
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. ---- Greg Kuperberg greg@math.berkeley.edu
ch@dce.ie (Charles Bryant) (04/12/91)
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.
eirik@wonton.TN.Cornell.EDU (Eirik Fuller) (04/19/91)
A related question: why does compress refuse to compress links? I think a warning message about a link would be entirely appropriate, since it would inform a user about the likelihood of the failure of compress to free up the space taken up by the original file. What if I don't want to free up that space? What if I want the file in both forms (compressed and uncompressed) without copying the uncompressed version? Utter refusal to leave a compressed copy of the file, particularly after it went to the trouble of compressing it first, seems to fit this Subject line pretty well. I understand that I could just "compress < file > file.Z ; rm file", but that doesn't preserve permissions and modtime.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/19/91)
(I am not sure this article is appropriate for comp.compression.) In article <EIRIK.91Apr18204209@wonton.TN.Cornell.EDU> eirik@wonton.TN.Cornell.EDU (Eirik Fuller) writes: > A related question: why does compress refuse to compress links? Because it's easy to write a program that replaces the link with a new copy. That solves the problem for all compressors. You can't expect compress to include everyone's favorite filesystem operation; it works fine for the vast majority of cases. ---Dan