Xref: utzoo comp.sources.bugs:2906 comp.compression:558
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!sparky!kent
From: kent@sparky.IMD.Sterling.COM (Kent Landfield)
Newsgroups: comp.sources.bugs,comp.compression
Subject: Problem with compress
Summary: Symlink compression creates more disk usage..
Keywords: compress bug symlinks
Message-ID: <1991May14.044431.23932@sparky.IMD.Sterling.COM>
Date: 14 May 91 04:44:31 GMT
Sender: kent@sparky.IMD.Sterling.COM (Kent Landfield)
Organization: Sterling Software, IMD
Lines: 39

I received an interesting question today, one I had never really considered.
"How does compress deal with symbolic links ?"  This was one of those
questions that you thought you knew, at least I did.  My first reaction
was to want to respond with "Why, it fails to compress the file, of course."
Before I said it, I realized that I really did not know.  I tried it out
and I was *suprised*.  It created a compressed copy of the file that the 
symlink had pointed to!

Here is what I did on a Sun 4/490 running 4.1.1 although a quick glance
at the source to compress let me know that this is a common problem...

lrwxrwxrwx   1 kent  kent  18 May 13 12:11 index -> /usenet/misc/index

When I typed "compress index"

index: Compression: 59.82% -- replaced with index.Z

-rw-rw-r--   1 kent     kent      57411 May 13 09:57 index.Z

OOPS!!....  It ignored the fact that the file was a symbolic link and created 
a compressed copy of the file. It did not touch the file that the symbolic link
referenced.  This is *NOT* what I wanted it to do... Compress fails on hard 
links but ignores symlinks altogether... ?? :-(

Have I missed something here ? Is this a known problem that some consider
a feature ?  I would much prefer that compress fail on symlinks as it does
on hard links.  How often have you "strolled" into a directory when space
was becoming a problem and typed "compress *" without even considering
which were symlinks and which were regular files ? (only 1/4 :-))

Wasn't the idea to save space instead of generate more disk usage ?
Has someone fixed this already ?

			-Kent+
-- 
Kent Landfield                   INTERNET: kent@sparky.IMD.Sterling.COM
Sterling Software, IMD           UUCP:     uunet!sparky!kent
Phone:    (402) 291-8300         FAX:      (402) 291-4362
Please send comp.sources.misc-related mail to kent@uunet.uu.net.