. file question (bug?)

[Brandon S. Allbery]

As quoted from <1670002 at hpcilzb.HP.COM> by tedj at hpcilzb.HP.COM (Ted Johnson):
+---------------
| In the following example, I created a directory and make 2 files.
| After deleting one of the files, the "." file thought that they
| were both still there.  Is this a bug???
| 
| hpcillm(tedj) 283>strings .
| file1
| file2
| hpcillm(tedj) 284>rm file2
| hpcillm(tedj) 285>strings .
| file1
| file2
| hpcillm(tedj) 286>ls
| file1
+---------------

A directory is an indexing mechanism for inodes, nothing more.  What you are
seeing with "strings" is only the ASCII portion of the directory; under non-
BSD directory formats, the actual representation of a file in a directory is:

	two-byte binary integer i-number
	14-character string filename

"Deleting" a file sets the i-number field to 0; this flags the entry as
reuseable, so doing a "touch ./file3" in that directory will reuse the slot
where file2 used to be.  This is needed because otherwise the kernel must
shift things around if you delete a file whose directory entry is in the
middle of the directory file, possibly having to shift many KB of data
around (granted, if that actually happens then the directory is for all
practical purposes overloaded, but many real-world (not to say RealWorld(tm)
;-) applications actually require this).  This is pretty much unacceptable
overhead, so the entry is merely marked for re-use later.

Berkeley UNIX does things a bit differently; under certain circumstances the
kernel will actually compact a directory (at least under 4.3BSD), but only
when it doesn't entail large amounts of overhead.  After all, how long do you
want to wait for the system to rm a file?

++Brandon
-- 
Brandon S. Allbery, uunet!marque!ncoast!allbery			DELPHI: ALLBERY
	    For comp.sources.misc send mail to ncoast!sources-misc