Xref: utzoo comp.sources.bugs:2920 comp.compression:584 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.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: <1991May17.164105.31731@mp.cs.niu.edu> Date: 17 May 91 16:41:05 GMT References: <26085: May1416: 52: 3491@kramden.acf.nyu.edu> <1991May15.060236.26763@uunet.uu.net> <1991May15.173739.29874@mp.cs.niu.edu> Followup-To: poster Organization: Northern Illinois University Lines: 38 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 Since I wrote that I have received several email messages, either agreeing or at least partially agreeing. One respondent did defend the current handling of hard links, suggesting that you shouldn't want to keep both a compressed and an uncompressed version. In my view, that misses the point. The software shouldn't make that decision for me - I should be able to make it myself. What I would often like to be able to do is: mkdir temp ln *.Z temp cd temp uncompress *.Z --------- browse through the uncompressed files ------------- cd .. rm -rf temp The current handling of hard links makes this a pain, although fortunately we have symlinks, so there is a work around. ---- Finally, apologies to comp.compression. I guess this discussion doesn't really belong there. It doesn't really belong in comp.sources.bugs either, although that is how I came upon it. Shortly after voting for comp.compression, I found myself unsubscribing due to the high noise level. And here I am contributing noise. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940