holes in files

[Dan Bernstein]

In article <1990Dec05.155248.8929 at iecc.cambridge.ma.us> johnl at iecc.cambridge.ma.us (John R. Levine) writes:
> In article <10960:Dec507:07:4190 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> >In article <1990Dec5.052124.28435 at erg.sri.com> zwicky at 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.
> On every modern version of Unix that I know of, there is no way for an
> application to tell the difference between a block of zeros and a hole other
> than poking at the raw disk.

#include <sys/types.h>
#include <sys/stat.h>

main()
{
 struct stat st;

 fstat(0,&st);
 printf("size on disk (not including holes) %ld\n",st.st_blocks);
}

> For that reason, an entirely reasonable strategy is always to leave a hole
> when writing a full block of zeros.

This is poor advice. An application may depend on the sizes of files it
creates.

> There may even be some versions of
> Unix that do that automatically in the write() call.

It's conceivable. So what?

---Dan