Often objects are referred to by various kinds of names,
like files by pathnames in filesystems, processes by process IDs,
web pages by URLs, variables and functions in source code by identifiers.
These names are kept with other objects and later used to access their
target.
E.g. pathnames are stored in symbolic links, process IDs of system
processes are stored in files in order to send signals to them,
identifiers are stored in object files for use by the linker.
There is no actual connection between the name stored somewhere and the
object.
If the object is destroyed or renamed, the name becomes invalid and
points into the void.
Later it might even point to a new, different object if the name was
reused.
Usually there is no efficient way (often no way at all) to detect or
avoid these problems.
The questions "are there still names pointing to this objects?"
and "where are those names?" can't be answered.
Therefore we should search for ways to replace names by a concept I call references: connections between objects that follow the objects when they're moved, and that can't outlive the objects they're connecting.
To a limited extent Unix' hardlinks are such references, they connect
pathnames to file contents and attributes stored in the inode.
Internally this mechanism uses names (the inode numbers).
These internal names are visible to the user but not directly usable,
there is no way to access a file by supplying an inode number.
The inodes carry a reference counter, counting all usable references to
themselves.
Thus one question can be answered: by looking at an inode, the number of
references to it can be determined.
The other question remains unanswered though, the references can't be
found without searching the whole filesystem.
Back to the main page.
Page created: Dec 13, 1997 -
last update: Nov 26, 2002 -
version 2.1
Jörg Czeranski (Impressum)