Automating Symbolic Link Generation
Clive King and Adrian Rixon
Users should need no more than minimal knowledge about
of the network they use. The layout of the filesystem
is only part
of a user's environment, but it is fundamental to their
of the network. Within a heterogeneous network, the
ideally appear the same to a user from all machines
on a network and
they should not need to understand the underlying network
required to present referential transparency.
This article addresses the problem of providing referential
(making a filesystem look the same from every location
on a network)
as regards system change and suggests a solution where
are used in combination with an automounter to give
the user a consistent
view of filesystems across the network.
With the large numbers of symbolic links required, it
is clearly not
feasible to generate all required symbolic links by
hand. Our solution
is a generator for symbolic links that takes a high-level
of the links to be constructed.
Because reference through multiple levels of symbolic
links can have
a significant impact on performance, we also present
a program for
identifying potential problem areas. [Editor's note:
The code for
these tools is too large to be published here but is
See the "Online Source Code" entry in the
table of contents for a
pointer to availability information.]
The Virtues of a Consistent Filesystem Structure
A consistent filesystem structure over time helps the
avoid many problems. For example, users need to be able
to set an
appropriate search path for the shell so that they can
software that they use. If the location of an item of
not only will the shell's path require changing, but
also any shell
scripts that have the path set explicitly and any binaries
commands via the shell using system or popen.
Applications, libraries, and initialization files must
be in the correct
locations, with the correct permissions, and must be
up to date in
relation to the software that uses them. If the location
of a library
is changed, then some applications may stop working
no apparent reason, especially if they are used infrequently.
applications may not be possible as the sources or the
time may not
X applications, for example, can find their defaults
file either by
using the default search directory which is set at compile
the environment variable XAPPLRESDIR. If the location
application's defaults file is changed, then the default
can be altered by setting XFILESEARCHPATH or XAPPLRESDIR
on a per-user basis. The alternative is recompilation
of the X server.
Both alternatives are inconvenient, and cause extra
work and confusion.
In the past, some applications have needed to be installed
in a specific
location. Although current versions of such software
appear to have
addressed this problem, older versions are still in
use and need access
to the resources they use. (Does this indicate that
the authors of
such software were never systems administrators?)
A Solution Strategy
At Aberystwyth, the amd automounter has formed a central
of our filesystem management strategy and is used in
place of the
Sun automounter. All amd maps are distributed via NIS,
allows centralized control of the maps and effective
across the network.
Referential transparency requires the implementation
of a naming scheme
that is independent of the physical location or type
of any item of
the hardware, the type or release of operating system,
and the role
of the machine. For established networks however, it
is not acceptable
to change the whole structure of a filesystem overnight
so as to adhere
to a new naming scheme. While a new structure is being
put in place,
the safe option is to mimic the old filesystem. In our
case, a significant
body of applications still access libraries or initialization
from a filesystem naming scheme that started to be phased
years ago. We addressed this problem by a combination
links and the link type of map entry under an automounter.
This approach allows a new naming scheme to be adopted
or the change
of use of individual disk partitions -- only the automounter
require alteration. We use a mount type of link to simulate
link of the old filesystem name in addition to a direct
the new name.
A large volume of nonsystem software is now used at
many sites. The
management and updating of this body of software is
task and is easier to manage if split into distinct
sections. At Aberystwyth
we have chosen the following division of non-system
TeX -- TeX, LaTeX and associated
gnu -- Free Software Foundation
X11R5 -- X software
lang -- Language software such as ADA, POPLOG
msdos -- MS-DOS applications for mounting
by PCs via PCNFS
misc -- Software that does not fit into
Each software division has its own disk partition, except
and X11R5, which share a disk partition. The Computer
has a class C network for teaching and for each of two
TeX and X11R5 are considered basic software and so are
on a server on each of the networks. This is done in
part for resiliency
and in part to reduce NFS traffic over routers between
The networks each have different LANG and MISC partitions
the different requirements of the groups that use the
each subnet. The MSDOS and GNU partitions exist on only
All files within each of the subdirectories of the above
categories have a symbolic link to the equivalent directory
This means that all non-system software is accessible
All non-system libraries can be set up to be accessible
and all non-system manual pages can be found in a subdirectory
/usr/local/man. This policy allows users to cut down
of items in their path and eliminates the need to change
when a new class of software is added; this responsibility
to the administrator.
The form of a user's path name is historical and cannot
overnight. To provide a shorter route to home directories,
keeping with history, a symbolic link is made from each
directory to a link of the same name in /home_link.
We deliberately made all solutions as simple as practical
new staff would not face too great a learning curve
with the site-specific aspects of the network setup.
Generating Symbolic Links
The large number of symbolic links required to provide
transparency makes it infeasible to generate all the
links by hand.
For example, one of our servers had 1176 symbolic links
in just /home_link
and /usr/local/bin. With over 100 UNIX machines on our
an automated method was clearly required.
To document and simplify the creation of symbolic links
filesystem for local software and to provide a shorter
route to a
user's home directory, we built a program that takes
of the form of symbolic links required and makes appropriate
links according to the description given. The links
are made between
a target and a source file or directory. The target
is the file to
which the new link is to be created. The source is the
file or directory
which is to be linked. For example, all executables
in source /usr/local/gnu/bin
are linked to a target of the same name in /usr/local/bin.
ls -l /usr/local/bin/gcc
lrwxrwxrwx 1 root 22 Nov 7 1992 \
/usr/local/bin/gcc -> /usr/local/gnu/bin/gcc
The syntax is of the form:
ROOT== root_path ;
search-depth== a value ;
type [ source -> target ];
ROOT is the source directory, such as /usr/local/TeX
or /usr/local/X11R5. The link type can be one of a number
of potential classes of symbolic link structures:
Single links -- Makes one-to-one links directly
from the source file to the target file.
Multiple links -- Makes links from all the files
of which source is the parent directory, to the subdirectory
Sub Multiple links -- Makes links from all the files
in the subdirectories of the source to files in newly
in the target directory, e.g., Man directory. Subdirectories
of the target are made as required.
The depth to which the links will be followed can be
set by using
search-depth. search-depth only applies to the sub_multi_link
class and has a default value of 20. A depth of 0 will
of only the files and immediate subdirectories of the
A depth of 1 will make links of all files and directories
in the immediate
subdirectories. To make links to all directories and
consideration of the depth of the directory tree, search
be set to an arbitrarily large value such as 20. For
multi_link[ bin -> /usr/local/bin ];
multi_link [ lib -> /usr/local/lib ];
sub_multi_link [ man -> /usr/local/man ];
multi_link[ mnt -> /home_link ];
The link generator takes the following command-line
in addition to the file describing the links to be made:
-l -- Makes a log of the links made in linker.log
-t -- Test mode, does not make symbolic
links, but goes through the motions
-a -- Requires an acknowledgment before
it makes a link
-b -- If the link exists, then carry on
to the next, makes a symbolic link only if a link does
-I -- Ignore and overwrite old links, no
-h -- syntax help
The symbolic link generator is written in C and uses
Yacc to interpret the specification files.
If you add new software to an established setup, you
must create further
links. You can do this either when installing the software
or by running
the link generator with the "-b" option at
When designing the layout of the filesystem you must
make sure that
symbolic links are only used on the client to access
the file in question
and that a mount is never attempted on a symbolic link.
should be used to mount all filesystems, and so avoid
of the symbolic links that are most inefficient. Therefore
link should only be used to directly access a file on
the client and
should never be placed on the server side of a mount.
of symbolic links should not exist.
NFS traffic over routers should be reduced as far as
can be achieved by providing all commonly used software
in a mirrored
partition from a server on each network.
Checking for Multiple Links
Within the link generator the function resolve_link
for multiple symbolic links. It attempts to make a link
the file itself if the target path is composed of a
series of symbolic
links. The compile time #define NO_LINK_RESOLVE can
to turn this feature off.
Also available is the program link_test, which can be
to analyze a filesystem in regard to the number of symbolic
and cross mounts. It resolves symbolic links and displays
of links and mount points, where the links exist, and
if a link exists
on the wrong side of a mount point.
The "-f" option to link_test will analyse
to every file that is in the argument directory.
link_test ignores any mount on / and can illuminate
Following path "/home/support/part_a/mnt/cmk"
"support" mounted on mount point "/home"
"mnt" is a symbolic link
"mnt" is a link on the wrong side of a mount
in path "/home/support/part_a/mnt"
"mnt" linked to directory "/a/athene/4.2/xy1e" -- now
"xy1e" mounted on mount point "/a/athene/4.2"
Path "/home/support/part_a/mnt/cmk" has :-
1 symbolic links
2 cross mounts
The method of managing filesystem structure presented
here can be
used to provide referential transparency across a heterogeneous
of UNIX machines. It allows the administrator to make
necessary for effective administration, while minimizing
change that the user has to cope with and the possibility
application might stop working for reasons associated
with these changes.
The AMD automounter with the automounter maps distributed
provides a centralized mechanism for the management
change. The physical location of a disk partition is
the user; therefore, the underlying structure of the
mounts can be
changed so long as the structure of the filesystem appears
to the user.
This article has presented an automated approach to
of symbolic links and a simple language for the description
links. The symbolic link generator greatly simplifies
of symbolic links on a network of machines.
Symbolic links can have a significant performance hit;
code distribution includes a short program to survey
and point out potential problems. In addition, the symbolic
attempts to reduce successive levels of symbolic links
in order to
make a link only to a regular file or directory.
Pendry, J. 1990. Amd Automounter Manual.
Sun Microsystems. December 1990. "Networks and
File Servers : A Performance Tuning Guide." Technical
The mailing list email@example.com
appears to be the best method of getting up to date
the status of amd.
About the Authors
Clive King is a member of the Centre for Intelligent
within the Department of Computer Science in the University
Aberystwyth. His duties include teaching UNIX systems
supporting research, and administering a network of
Prior to this, he was a Systems Administrator at the
the national Mapping agency in the U.K. His research
in the area of distributed systems and concurrent programming.
Adrian Rixon is a Systems Administrator within the Department
of Computer Science in the University of Wales, Aberystwyth.
interests are in the areas of information discovery
in Wide Area Networks and network security.