Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!sparkyfs.erg.sri.com!zwicky
From: zwicky@erg.sri.com (Elizabeth Zwicky)
Newsgroups: comp.unix.internals
Subject: Re: How do you find the symbolic links to files.
Message-ID: <1990Dec5.052124.28435@erg.sri.com>
Date: 5 Dec 90 05:21:24 GMT
References: <25146@adm.brl.mil>
Sender: news@erg.sri.com
Organization: SRI International, Menlo Park, CA
Lines: 49

> So, whats the real truth about find, cpio & tar? how do they behave?

There is no real truth about find, cpio, and tar, all of which are
relatively notorious for behaving differently on different versions of
UNIX (and, for all I know, may be available for things like MS-DOS,
where all bets are off). What you want to know, presumably, is what
the real truth is about *your* find, cpio, and tar; if the manual
doesn't tell you, I suggest experimentation. (If it does tell you, I
still suggest experimentation if you care a whole lot - often the
manual lies.) At least specify exactly what OS, and yes, the release
number matters.

Just to spread gloom among the populace, let me point out that those
of you who rest secure in the belief that your tar correctly handles
symbolic links, and thus will not erroneously expand your file system,
are unjustifiably optimistic. I know of at least two ways in which a
supposedly well-behaved tar can turn your 10 meg of data from your 16
meg partition into a tape-sucking nightmare, only one of which I
comprehend. There is this cute little concept of files with holes in
them; the file system can omit blocks full of nulls, and essentially
replace them with little signs that say "and when you get here, there
should be 20 meg of nulls, OK?" This is a useful trick, since sparsely
allocated tables can be useful things to write to disk - both core
dumps and dbm databases make use of it lavishly. Unfortunately, you
have to get pretty intimate with the disk to tell that the 20 meg of
nulls aren't there (well, it's not that unfortunate, since it is
rather the point of the exercise, but it is at times inconvenient).
tar in many versions, as a matter of principle, cuddles up to the
filesystem like a user program, and doesn't romp through disk blocks.
Thus, it happily fills in all the holes. I have a friend who
discovered this little trick when he tried to restore a 16 meg root
partition on a machine with 32 meg of VM. There was a core file in it.
The 40-odd meg of data on his tape did not fit well into the 16 meg
partition. Luckily, it was a test restore, and I'm sure you can all
figure out the moral to *that* story.

The other way to turn tar into a raging monster is frankly unlikely to
happen to anyone else; we tarred off an NFS mounted partition from a
VMS machine which had a pathological nameless directory on it.
Something caused the UNIX side to believe that the nameless directory
was some sort of link to ., and tar recursed its little heart out.
There are a lot of reasons why this should not have happened, but it
did, and the only reason that it didn't run until the tape filled is
that it ran out of path name space first, a few recursions down. This
is the only good thing I have to say about the concept of having a 128
character path-name limit in a program, when the OS does not have the
same limit...

	Elizabeth Zwicky