Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lanl!cmcl2!adm!xadmx!rroba.DlosLV@xerox.com
From: rroba.DlosLV@xerox.com
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you want in the GNU OS
Message-ID: <19964@adm.BRL.MIL>
Date: 10 Jun 89 06:40:39 GMT
Sender: news@adm.BRL.MIL
Lines: 28

In message <14460.8906081609@orchid.warwick.ac.uk>,  somebody says:
>In article <19889@adm.BRL.MIL> you write:
>> (I am assuming that everybody in the audience understands the impact
>> of a symbolic link on the amount of time required to open a file.)
>
>No, I don't -- can you explain it please

When you attempt to open a file, you specify a path name.  Before the file
can be opened, the kernel must translate the file name into an inode number
(the inode must be obtained to determine the location and size of the file
on the disk drive).   The inode number is recorded in the directory of the
file.  So, the kernel must open (access) the directory to read the inode
number of the file; but before it can open the directory, it must first
determine the inode number of the directory . . .  and so on to the root
directory.  This process actually begins, of course, with the root
directory (at least in the case of absolute path names), and traces up to
the file (opening directories and extracting the next inode number along
the way).

In the case of symbolic links, this process is interrupted when the kernel
finds, in some intermediate directory, not an inode number, but an
alternate path name.  At this point the kernel must begin again at the root
directory, retracing it's steps through another sequence of directories.

The difficulty of extracting an inode number from this sequence of
directories is further complicated in BSD systems by the complexity of BSD
directories, which are structured in a manner similar to a linked list (as
opposed to AT&T directories, which are more like arrays of structs).