Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu!uwvax!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Can directory files have holes in them ?
Message-ID: <20044@mimsy.UUCP>
Date: 7 Oct 89 15:32:41 GMT
References: <1212@accuvax.nwu.edu> <442@ecs.soton.ac.uk> <1240@virtech.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 25

In article <1240@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>[someone's] example shows a regular file with holes in it.  The
>original poster was asking about a directory file with holes in it.  I,
>for one, cannot figure any way you could get holes in a directory
>because the mechanism to generate holes is to lseek beyond the end of
>the file and write some information, thereby generating a hole between
>the old end of the file and the new data (assuming there was at least 1
>full block between the two.

Well, actually, it is by setting an offset (uio->uio_offset, or
u.u_offset in other kernels) sufficiently large so that when bwrite()
calls bmap(), and bmap() finds there is no data block for the given
offset, and the kernel allocates one, that one happens to be `after' an
offset that also has no data block.  (Sometimes necessary indirect
blocks are also missing, and the allocation gets complicated, but it
all works out the same.)

Anyway, holes in a directory would be invalid in 4.2 and 4.3BSD because
the d_reclen field should never be zero.

The original question was why dump is careful not to look at holes
in directories.  The only possible answer is `paranoia'.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris