🚀 go-pugleaf

In article <26085:May1416:52:3491@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>(I'm not sure whether this is appropriate for comp.compression.)

??? I must be confused about the charter of comp.compression. Sorry...

>In article <1991May14.044431.23932@sparky.IMD.Sterling.COM> kent@sparky.IMD.Sterling.COM (Kent Landfield) writes:
>> I received an interesting question today, one I had never really considered.
>> "How does compress deal with symbolic links ?"
>
>compress isn't a BSD program. It uses stat(), and its behavior makes
>perfect sense.

It is not a "BSD" program in that it does not use lstat to detect symlinks,
that is correct and the problem....  Compress has come into wide use on BSD 
based environments and is and has been delivered from vendors of those
environments... I am not sure when AT&T started delivering it... :-)

I cannot agree with the "perfect sense" statement. Why does compress not
deal with hard links ? Because it would have to know the location of the 
other link(s) so that it could rename it/them with a .Z compression suffix. 
This was too much for a compression program to deal with so compress does not.
Why is a symbolic link any different in this case ? I can and do have symlinks
that point to other symlinks... Compress actually alters the file type from a
symlink to a regular file in no time flat... I don't see why, after all the
years that compress has been around that this is not in the BUGS section
of the man page. At least it is not in the man pages from the vendors I
have in house and the sources I have from the net...

>I think compressors should ignore problems like this. They shouldn't
>open files, they shouldn't close files, they shouldn't do anything but
>read data and write compressed data. This also makes them more portable.
>A separate, system-dependent program can do the dirty work.

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)
			-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.