Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!wuarchive!udel!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: holes in files
Message-ID: <6193:Dec618:43:4390@kramden.acf.nyu.edu>
Date: 6 Dec 90 18:43:43 GMT
References: <1990Dec5.052124.28435@erg.sri.com> <10960:Dec507:07:4190@kramden.acf.nyu.edu> <1990Dec05.155248.8929@iecc.cambridge.ma.us>
Organization: IR
Lines: 35

In article <1990Dec05.155248.8929@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes:
> In article <10960:Dec507:07:4190@kramden.acf.nyu.edu> 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.
> 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