Xref: utzoo comp.sources.bugs:2917 comp.compression:577
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.sources.bugs,comp.compression
Subject: Re: Problem with compress
Message-ID: <14499:May1522:45:0491@kramden.acf.nyu.edu>
Date: 15 May 91 22:45:04 GMT
References: <26085: May1416: 52:3491@kramden.acf.nyu.edu> <1991May15.060236.26763@uunet.uu.net> <1991May15.173739.29874@mp.cs.niu.edu>
Organization: IR
Lines: 17

In article <1991May15.173739.29874@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>  Am I alone in thinking that the way compress handles symlinks is just fine.
> What I don't like is the way it handles hard links.  What would be wrong with
> 'compress foo' just creating the compressed 'foo.Z' and deleting 'foo', and
> 'uncompress foo.Z' creating the uncompressed 'foo' and removing 'foo.Z'?

I'm sure someone would complain that uncompress didn't exactly reverse
the effect of compress. It doesn't in the symlink case either, but
anything can be sacrificed to the Great God Portability.

Peter hinted at the optimal solution: compress should replace the file
contents without changing any of its links, and when the file is read,
the filesystem should automatically realize that the file contents are
compressed and uncompress them for you. (Now that I'm talking about the
Plan 9 filesystem I'm sure that this belongs in comp.unix.programmer.)

---Dan