Xref: utzoo comp.sources.bugs:2915 comp.compression:573 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.sources.bugs,comp.compression Subject: Re: Problem with compress Message-ID: <1991May15.173739.29874@mp.cs.niu.edu> Date: 15 May 91 17:37:39 GMT References: <1991May14.044431.23932@sparky.IMD.Sterling.COM> <26085: May1416: 52:3491@kramden.acf.nyu.edu> <1991May15.060236.26763@uunet.uu.net> Organization: Northern Illinois University Lines: 23 In article <1991May15.060236.26763@uunet.uu.net> kent@uunet.UU.NET (Kent Landfield - comp.sources.misc) writes: >>> "How does compress deal with symbolic links ?" > >I was not talking about the way it should be. I was talking about a bug, >as far as I am concerned, in the way compress exists today. I was hoping >that someone had fixed this and I would not have to... :-( I am still >hoping. (hint, hint) 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'? If I want to keep a copy of both compressed and uncompressed for my own reasons, why shouldn't I be able to do that by making a hard link before I compress or uncompress? Making me copy the file is just plain stupid. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940