Xref: utzoo comp.unix.wizards:23931 comp.unix.internals:1928
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!mel.dit.csiro.au!yarra!bacchus!david
From: david@bacchus.esa.oz.au (David Burren)
Newsgroups: comp.unix.wizards,comp.unix.internals
Subject: Re: holes in files
Summary: got it thanks
Keywords: filesystems
Message-ID: <1119@bacchus.esa.oz.au>
Date: 31 Jan 91 08:42:27 GMT
References: <1111@bacchus.esa.oz.au>
Organization: Expert Solutions Australia
Lines: 26

In article <1111@bacchus.esa.oz.au>, david@bacchus.esa.oz.au (David Burren) writes:
> Where can I find mention of the implementation of "holes" in files under
> the BSD ffs or other filesystems?
> Do I guess and assume that the relevant block pointer(s) have some
> sentinel value (eg. 0) to flag the fact that there is no data?

Thank you all who have responded.  Apparently that is how it's done.
One respondent noted that block 0 on the disks he'd looked at were
zeroed out and that that's why reading a hole returned zeros, but those
must have been non-boot disks that for some reason had block 0 cleared.
I was under the impression that it wasn't used on non-boot volumes.

Anyway, I'm told that the fs code interprets the 0 pointer as being to an
unallocated block no matter what the values in block 0 are.

Thanks folks, I don't think I need any more email on the subject....


> BTW, under some OSes I've seen processes with sparse address maps produce
> core dumps with holes in them.  I once had a user ask me "how can I make my
> file a core file?"  He was a student trying to get around quotas....

Yes folks, that time it was a SunOS 4.x machine.  Is anyone aware of other
flavours of Unix/etc that regularly exhibit the same behaviour?

- David B.