Can directory files have holes in them ?

[John Bruner]

In article <20044 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>The original question was why dump is careful not to look at holes
>in directories.  The only possible answer is `paranoia'.

The paranoid code in dump and the kernel was added because of a
problem I ran into at Purdue on either a V7 PDP-11 or 4.1BSD VAX
(probably an 11/70) several years ago.  A hardware problem caused
a block pointer in a directory inode to be zeroed.  (I do not
remember the exact circumstances, except that it was a hardware
problem and it did not totally destroy the disc.)  "fsck" passed
the filesystem without a complaint, but any attempt to access the
directory (which I recall was something innocuous like "/usr/bin")
caused a panic.

In those days I believe that namei() did something like

	bp = bread(ip->i_dev, bmap(ip, lbn, B_READ));

The bug was that namei() didn't check whether bmap() returned -1
because holes in directories were "impossible".  My fix was to report
the hole on the console and allocate a new block if the filesystem
was mounted read/write; otherwise, it just skipped to the next block.
As I recall, "fsck" had code which checked for holes in files, but it
was commented out.  I turned on the check for directories.
I sent mail to Berkeley, and they integrated these changes into the
4.2BSD filesystem code (although they removed the code which filled
in the hole).
--
John Bruner	Center for Supercomputing R&D, University of Illinois
	bruner at uicsrd.csrd.uiuc.edu	(217) 244-4476