Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!world!iecc!johnl
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.unix.internals
Subject: Re: holes in files
Message-ID: <1990Dec05.155248.8929@iecc.cambridge.ma.us>
Date: 5 Dec 90 15:52:48 GMT
References: <25146@adm.brl.mil> <1990Dec5.052124.28435@erg.sri.com> <10960:Dec507:07:4190@kramden.acf.nyu.edu>
Organization: I.E.C.C.
Lines: 24
Old-Subject: Re: How do you find the symbolic links to files.

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.  The file size is the logical file size
including the holes, e.g. if you seek out to byte 1000000 and write
something, the file size will be 1000000 even though the file is mostly
holes.

For that reason, an entirely reasonable strategy is always to leave a hole
when writing a full block of zeros.  There may even be some versions of
Unix that do that automatically in the write() call.

-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
"Typically supercomputers use a single microprocessor." -Boston Globe