How do you find the symbolic links to files.

[Elizabeth Zwicky]

In article <110689 at convex.convex.com> tchrist at convex.COM (Tom Christiansen) writes:
>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?

Actually, I can produce a very strained example where an otherwise
working program that does not know anything about which blocks are
filled on disks and which aren't nevertheless breaks if holes are
restored in the wrong places. Postulate a program that has data which
includes stretches of nulls that will always be nulls, and stretches
that may change to other things. It then pre-allocates a file for the
data, lseeking over the always null parts, and writing nulls for the
parts that may change. Note that it does not care what the results of
this are; the OS can make holes for the lseeks or not, as it pleases.
However, that program can now assume that it has enough space to run
in.

If you restore it with all holes, you have freed space that something
else may eat before the program wants it. If you restore it with the
same number of holes  it had before, but in different places, the file
is no longer guaranteed to be a static length; when the
known-to-be-changeable nulls change, the program may have to fill in a
hole, and once again may not have the space it needs. 

I must admit that I can't produce any live examples of programs that
do this, any more than I can produce any live examples of programs
that care where their holes are for other reasons, or that care what
st_blocks is. But this seems to me to be a defensibly non-broken
behaviour.

	Elizabeth Zwicky