Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: cwd inodep vs. path prefix
Message-ID: <6052@brl-smoke.ARPA>
Date: Sat, 4-Jul-87 17:46:54 EDT
Article-I.D.: brl-smok.6052
Posted: Sat Jul  4 17:46:54 1987
Date-Received: Sun, 5-Jul-87 01:20:06 EDT
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 11

It has been pointed out to me off-line that current UNIX implementations
maintain the CWD as an inode pointer, so actually all the stat info is
kept resident, not just the dev+inumber.  (Actually I knew this, but
I've gotten into the habit of thinking of the sys+dev+inumber as the
unique handle for an inode.)  The main advantage to this approach is
that it is more efficient to access the inode when opening a relative
pathname than to find one from a prefix, even if a clever implementation
(hashing, caching, etc.) is used for prefixes.  The main disadvantage as
I see it is that special filesystem types have to pretend to support a
directory structure like the disk file system, including manufacturing
".." entries (for /bin/pwd).