Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!adm!umd5!eneevax!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: . file question (bug?)
Summary: reading directories with `strings' is silly
Message-ID: <12847@mimsy.UUCP>
Date: 5 Aug 88 08:05:20 GMT
References: <1670002@hpcilzb.HP.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 34

In article <1670002@hpcilzb.HP.COM> tedj@hpcilzb.HP.COM (Ted Johnson) writes:
>When does the "." file, which describes the current directory,
>get updated?

Whenever it gets updated.  `.' is a *link* to that directory.  Any
change to that directory is reflected immediately, because the name `.'
resolves to that directory.

>hpcillm(tedj) 279>strings .
>hpcillm(tedj) 280>touch 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
>hpcillm(tedj) 287>exit

As the `ls' shows, file2 has been deleted.  The directory has been
rewritten so that the `inode number' associated with the entry for
file2 is zero: this marks a free slot.  A free slot can have any
sort of trash in its name field, which is why one reads directories
with `readdir' or `ls' (portable readdir implementations are available
for those whose vendors fail to supply them; e.g., Doug Gwyn has one).
It just happens that the Unix system you have leaves the old name
there.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris