. file question (bug?)

[Randal L. Schwartz @ Stonehenge]

In article <1670002 at hpcilzb.HP.COM>, tedj at hpcilzb (Ted Johnson) writes:
| 
| When does the "." file, which describes the current directory,
| get updated?  Only when you do an fsck?
[ ... ]
| Script started on Wed Aug  3 11:06:39 1988
| hpcillm(tedj) 277>mkdir testdir
| hpcillm(tedj) 278>cd testdir
| ./testdir
| hpcillm(tedj) 279>strings .
| hpcillm(tedj) 280>touch file1
| hpcillm(tedj) 281>strings .
| file1
| hpcillm(tedj) 282>touch file2
| hpcillm(tedj) 283>strings .
| file1
| file2
| hpcillm(tedj) 284>rm file2
| hpcillm(tedj) 285>strings .
| file1
| file2
| hpcillm(tedj) 286>ls
| file1

(Lezzeee if I can do this better than I did the ctime field, sheesh...)

A directory file (like the one referenced by ".") is not a text file.
In original UN*X (as DMR et. al. intended it :-), a directory
consisted of one or more 16-byte entries.  Each entry had two bytes
for an Inode number, and 14 bytes for the file name (null-padded on
the right if the name was shorter than 14 bytes).  When a file was
deleted, only the two Inode bytes had to be changed, to zero,
specifically, since the zero Inode was reserved.  But, the value of
the filename remained.

strings(1) ignores the presence or absence of the zero-inode
indication.  For more accurate results, repeat your example, but use
"od -c" every place you used "strings".  You'll see Inode numbers come
and go, the same way the UN*X kernel handles them.

(Well, gurus?  Can I keep my UNIX Driver's License card now?)

Yours for a better tomorrow,
-- 
Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095
on contract to BiiN Technical Publications (for now :-), Hillsboro, Oregon
<merlyn at intelob.intel.com> or ...!tektronix!ogcvax!omepd!intelob!merlyn
Standard disclaimer: I *am* my employer!