p1

unix v7是最后一个广泛发布的研究型UNIX版本

he may also create subdirectories to contain
groups of files conveniently treated together.
A directory behaves exactly like an ordinary file except that it
cannot be written on by unprivileged programs, so that the system
controls the contents of directories.
However, anyone with
appropriate permission may read a directory just like any other file.
.PP
The system maintains several directories
for its own use.
One of these is the
.UL root
directory.
All files in the system can be found by tracing
a path through a chain of directories
until the desired file is reached.
The starting point for such searches is often the
.UL root .
Other system directories contain all the programs provided
for general use; that is, all the
.IT commands .
As will be seen, however, it is by no means necessary
that a program reside in one of these directories for it
to be executed.
.PP
Files are named by sequences of 14 or
fewer characters.
When the name of a file is specified to the
system, it may be in the form of a
.IT path
.IT name ,
which
is a sequence of directory names separated by slashes, ``/\^'',
and ending in a file name.
If the sequence begins with a slash, the search begins in the
root directory.
The name
.UL /alpha/beta/gamma
causes the system to search
the root for directory
.UL alpha ,
then to search
.UL alpha
for
.UL beta ,
finally to find
.UL gamma
in
.UL beta .
.UL \&gamma
may be an ordinary file, a directory, or a special
file.
As a limiting case, the name ``/\^'' refers to the root itself.
.PP
A path name not starting with ``/\^'' causes the system to begin the
search in the user's current directory.
Thus, the name
.UL alpha/beta
specifies the file named
.UL beta
in
subdirectory
.UL alpha
of the current
directory.
The simplest kind of name, for example,
.UL alpha ,
refers to a file that itself is found in the current
directory.
As another limiting case, the null file name refers
to the current directory.
.PP
The same non-directory file may appear in several directories under
possibly different names.
This feature is called
.IT linking ;
a directory entry for a file is sometimes called a link.
The
.UX
system
differs from other systems in which linking is permitted
in that all links to a file have equal status.
That is, a file does not exist within a particular directory;
the directory entry for a file consists merely
of its name and a pointer to the information actually
describing the file.
Thus a file exists independently of any
directory entry, although in practice a file is made to
disappear along with the last link to it.
.PP
Each directory always has at least two entries.
The name
``\|\fB.\|\fP'' in each directory refers to the directory itself.
Thus a program
may read the current directory under the name ``\fB\|.\|\fP'' without knowing
its complete path name.
The name ``\fB\|.\|.\|\fP'' by convention refers to the parent of the
directory in which it appears, that is, to the directory in which
it was created.
.PP
The directory structure is constrained to have the form
of a rooted tree.
Except for the special entries ``\|\fB\|.\|\fP'' and ``\fB\|.\|.\|\fP'', each directory
must appear as an entry in exactly one other directory, which is its
parent.
The reason for this is to simplify the writing of programs
that visit subtrees of the directory structure, and more
important, to avoid the separation of portions of the hierarchy.
If arbitrary links to directories were permitted, it would
be quite difficult to detect when the last connection from
the root to a directory was severed.
.SH
3.3 Special files
.PP
Special files constitute the most unusual feature of the
.UX
file system.
Each supported I/O device
is associated with at least one such file.
Special files are read and written just like ordinary
disk files, but requests to read or write result in activation of the associated
device.
An entry for each special file resides in directory
.UL /dev ,
although a link may be made to one of these files
just as it may to an ordinary file.
Thus, for example,
to write on a magnetic tape
one may write on the file
.UL /dev/mt .
Special files exist for each communication line, each disk,
each tape drive,
and for physical main memory.
Of course,
the active disks
and the memory special file are protected from
indiscriminate access.
.PP
There is a threefold advantage in treating
I/O devices this way:
file and device I/O
are as similar as possible;
file and device names have the same
syntax and meaning, so that
a program expecting a file name
as a parameter can be passed a device
name; finally,
special files are subject to the same
protection mechanism as regular files.
.SH
3.4 Removable file systems
.PP
Although the root of the file system is always stored on the same
device,
it is not necessary that the entire file system hierarchy
reside on this device.
There is a
.UL mount
system request with two arguments:
the name of an existing ordinary file, and the name of a special
file whose associated
storage volume (e.g., a disk pack) should have the structure
of an independent file system
containing its own directory hierarchy.
The effect of
.UL mount
is to cause
references to the heretofore ordinary file
to refer instead to the root directory
of the file system on the removable volume.
In effect,
.UL mount
replaces a leaf of the hierarchy tree (the ordinary file)
by a whole new subtree (the hierarchy stored on the
removable volume).
After the
.UL mount ,
there is virtually no distinction
between files on the removable volume and those in the
permanent file system.
In our installation, for example,
the root directory resides
on a small partition of one of
our disk drives,
while the other drive,
which contains the user's files,
is mounted by the system initialization
sequence.
A mountable file system is generated by
writing on its corresponding special file.
A utility program is available to create
an empty file system,
or one may simply copy an existing file system.
.PP
There is only one exception to the rule of identical
treatment of files on different devices:
no link may exist between one file system hierarchy and
another.
This restriction is enforced so as to avoid
the elaborate bookkeeping
that would otherwise be required to assure removal of the links
whenever the removable volume is dismounted.
.SH
3.5 Protection
.PP
Although the access control scheme
is quite simple, it has some unusual features.
Each user of the system is assigned a unique
user identification number.
When a file is created, it is marked with
the user \*sID\*n of its owner.
Also given for new files
is a set of ten protection bits.
Nine of these specify
independently read, write, and execute permission
for the
owner of the file,
for other members of his group,
and for all remaining users.
.PP
If the tenth bit is on, the system
will temporarily change the user identification
(hereafter, user \*sID\*n)
of the current user to that of the creator of the file whenever
the file is executed as a program.
This change in user \*sID\*n is effective only
during the execution of the program that calls for it.
The set-user-\*sID\*n feature provides
for privileged programs that may use files
inaccessible to other users.
For example, a program may keep an accounting file
that should neither be read nor changed
except by the program itself.
If the set-user-\*sID\*n bit is on for the
program, it may access the file although
this access might be forbidden to other programs
invoked by the given program's user.
Since the actual user \*sID\*n
of the invoker of any program
is always available,
set-user-\*sID\*n programs
may take any measures desired to satisfy themselves
as to their invoker's credentials.
This mechanism is used to allow users to execute
the carefully written
commands
that call privileged system entries.
For example, there is a system entry
invokable only by the ``super-user'' (below)
that creates
an empty directory.
As indicated above, directories are expected to
have entries for ``\fB\|.\|\fP'' and ``\fB\|.\|.\|\fP''.
The command which creates a directory
is owned by the super-user
and has the set-user-\*sID\*n bit set.
After it checks its invoker's authorization to
create the specified directory,
it creates it and makes the entries
for ``\fB\|.\|\fP'' and ``\fB\|.\|.\|\fP''.
.PP
Because anyone may set the set-user-\*sID\*n
bit on one of his own files,
this mechanism is generally
available without administrative intervention.
For example,
this protection scheme easily solves the \*sMOO\*n
accounting problem posed by ``Aleph-null.''
.[
aleph null software practice
.]
.PP
The system recognizes one particular user \*sID\*n (that of the ``super-user'') as
exempt from the usual constraints on file access; thus (for example),
programs may be written to dump and reload the file
system without
unwanted interference from the protection
system.