How do you find the symbolic links to files.

[Dan Bernstein]

In article <1990Dec5.190610.5612 at dg-rtp.dg.com> goudreau at larrybud.rtp.dg.com (Bob Goudreau) writes:
> In article <10960:Dec507:07:4190 at kramden.acf.nyu.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> > > Unfortunately, you
> > > have to get pretty intimate with the disk to tell that the 20 meg of
> > > nulls aren't there
> > Hardly. You just look at the file size. Other than the file size,
> > there is no way a portable program can tell the difference between
> > a hole and an allocated block of zeros.  If an archiver knows the
> > block size and sees that a file has N holes, it can just squish the
> > first N holes it finds, and write explicit zeros in the remaining
> > zero-filled blocks.
> By "file size" and "portable", I assume that you are talking about
> the st_size field of the POSIX.1-defined struct stat.

No, I was referring to BSD st_blocks. (Is there really no equivalent
under System V?) As you say about it:

> it tells you nothing about the number and location of holes
> in the file.

That's quite correct. In the article you're responding to, I wrote ``it
can just squish the first N holes it finds, and write explicit zeros in
the remaining zero-filled blocks.'' One might infer from this that there
is no way to detect the locations of the holes. So what?

> A truly portable method must use only standard functions (such as the
> ones defined in POSIX.1) and must assume nothing at all about block
> sizes or any other aspects of the file system structure.

Well, if a POSIX system doesn't have st_blocks, then obviously a
portable program can't figure out that a file has holes, so there's no
point to figuring out how many holes there are. But every POSIX-based
system I've seen does have st_blocks.

> The obvious
> way to do this is to have the archiver program read() all <st_size>
> bytes of the file while keeping an eye out for long stretches of
> 0-valued bytes so that it can store them in a special space-saving
> manner in its archive.

This is only slow on files that do have holes, and then only on long
stretches of zeros.

> Unfortunately, while such
> an approach is portable, its performance will leave something to be
> desired on files with truly tremendous holes in them; much time will
> be wasted on read()ing the holes.

No, there won't be any read() time wasted. There will be CPU time
wasted. (Tom points out in another article that vectorization helps
here.)

Yes, it would be nice to have a way to see where the holes are.

---Dan