Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: How do you find the symbolic links to files.
Message-ID: <6454:Dec619:00:5290@kramden.acf.nyu.edu>
Date: 6 Dec 90 19:00:52 GMT
References: <1990Dec5.052124.28435@erg.sri.com> <10960:Dec507:07:4190@kramden.acf.nyu.edu> <1990Dec5.183223.28304@specialix.co.uk>
Organization: IR
Lines: 22

In article <1990Dec5.183223.28304@specialix.co.uk> jonb@specialix.co.uk (Jon Brawn) writes:
> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >In article <1990Dec5.052124.28435@erg.sri.com> zwicky@erg.sri.com (Elizabeth Zwicky) 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.
> Umm? really? I wrote this program:
  [ ... ]
> 	printf("st_size %d\n",statb.st_size);

That is the logical size. The actual size on disk is st_blocks.

> Now, please demonstrate to your audience where the holes can be detected?

In a previous article.

---Dan