Can directory files have holes in them ?

John Chambers jc at minya.UUCP
Thu Oct 12 09:28:54 AEST 1989


In article <1240 at virtech.UUCP>, cpcahil at virtech.UUCP (Conor P. Cahill) writes:
> The kernel shouldn't have any reason to seek beyond the end of the file and
> therefore shouldn't create a directory with holes in it - But this is 
> only guesswork.

Oh, I don't know about that; I immediately thought of a way it could 
reasonably happen.  Older Unix systems have a notable problem in the
fact that directories can only grow; there is no mechanism for freeing
the space after a lot of deletions.  One common example is the various
subdirectories of /usr/spool.  Suppose there were a clever routine that
scanned thru large directories, and if there were no in-use entries in
a block, returned it to the free-space list.  This would solve the space
problem nicely.  It'd also help if the directory scanner would notice
the missing blocks, and silently skip over them.

I'm not saying that BSD does this; in fact, I've seen claims that it
moves entries about to compact directories, and frees the blocks from
the end.  This is a bit more work, true, but it wouldn't produce holes
(and all the annoying POSSIBLE FILE SIZE ERROR messages from fsck :-).

Of course, if you have people twiddling the filesystem via fsdb or their
own programs (as in the suggestions re my recent query), it'd be quite
easy to produce a directory with holes.  In any case, holes are legal,
if uncommon, and programs should handle them correctly.

Which reminds me:  If I wanted to test a program of mine for validity
in the face of holey directories, how would I go about producing one?
Legally, I mean, not by twiddling the raw device.  (I know how to do 
that, and I don't like it much; I'd much rather open the directory for 
writing. ;-)  In general, I like to test my code against all the possible
pathological cases, which means that I have to find ways to produce them.
In my mind, a system that won't let me generate a library of "garbage"
files is somewhat deficient as a development system; such deficiencies
are a sign of poor engineering.

-- 
#echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:'
echo '	John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)'
echo ''
saying



More information about the Comp.unix.wizards mailing list