. file question (bug?)

[Root Boy Jim]

? When does the "." file, which describes the current directory,
? get updated?  Only when you do an fsck?  

? 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) 279>strings .

Your problem is your use of the `strings' command. Allow me to explain
the situation by lying a bit.

Once upon a time, directory entrys were 16 bytes long. Fourteen of these
characters were the file name, zero terminated if less than 14 chars.
The other two were the inode number *if nonzero*, or an `empty slot'
*if zero*. To remove an file from a directory, UNIX looks up the name,
gets the inode, unlinks the file, and then sets the inode in the directory
to zero. It *does not* do anything with the 14 char name field (why bother?).

To add a new file to a directory, the system gets a new inode, looks
for an empty slot (it extends the directory if none is found), and
stores the (inode number, filename) pair in the slot.

The above is still true on Berkeley based systems with the following
complications: directory entrys are variable sized, with appropriate
char counts of the name field to handle the new format.

BTW, fsck will not remove the names either as far as I know.

The `ls' command ignores empty slots, but `strings' will find old names.

	(Root Boy) Jim Cottrell	<rbj at icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688
	The opinions expressed are solely my own
	and do not reflect NBS policy or agreement
	Careful with that VAX Eugene!