Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!adm!xadmx!rbj@nav.icst.nbs.gov From: rbj@nav.icst.nbs.gov (Root Boy Jim) Newsgroups: comp.unix.wizards Subject: . file question (bug?) Message-ID: <16807@adm.ARPA> Date: 12 Aug 88 16:59:05 GMT Sender: news@adm.ARPA Lines: 37 ? 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 CottrellNational 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!