Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!texsun!letni!mic!convex!convex.COM
From: tchrist@convex.COM (Tom Christiansen)
Newsgroups: comp.unix.internals
Subject: Re: How do you find the symbolic links to files.
Message-ID: <110689@convex.convex.com>
Date: 12 Dec 90 05:42:51 GMT
References: <2469:Dec1001:13:4390@kramden.acf.nyu.edu> <1990Dec10.191522.2757@erg.sri.com> <2993:Dec1202:37:2090@kramden.acf.nyu.edu>
Sender: usenet@convex.com
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Software Development, Richardson, TX
Lines: 24

In article <2993:Dec1202:37:2090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
:> I conclude from this that good archivers are not portable. One can
:> arguably conclude that if you want a portable program, you can in good
:> conscience restore files with as many holes as possible, since you
:> can't get it right.

:No! This is what Tom said, and it is entirely wrong. On a BSD system the
:right strategy is #2: do what's necessary to restore st_blocks. A
:program can reasonably depend on that information, so an archiver that
:doesn't restore st_blocks is buggy.

Taking my name in vain again, I see. :-)

I'll boldly state that any *application* (dump programs don't count) that
relies on whether or not a block of nulls is or isn't really allocated on
the disk is broken, and therefore it doesn't matter if you put in more
holes than were there.  Can anyone show me a case where it would break
something?

--tom
--
Tom Christiansen		tchrist@convex.com	convex!tchrist
"With a kernel dive, all things are possible, but it sure makes it hard
 to look at yourself in the mirror the next morning."  -me