unix time_share_system .htm

讲解关于UXIX操作系统的资料,包含如何基本操作以及编程.

be passed a device name; finally, special files are subject to the same 
protection mechanism as regular files. </P>
<H4>3.4 Removable file systems </H4>
<P>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 <I>mount</I> 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 <I>mount</I> 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, <I>mount</I> 
replaces a leaf of the hierarchy tree (the ordinary file) by a whole new subtree 
(the hierarchy stored on the removable volume). After the <I>mount</I>, 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. </P>
<P>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. </P>
<H4>3.5 Protection </H4>
<P>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 ID 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. </P>
<P>If the tenth bit is on, the system will temporarily change the user 
identification (hereafter, user ID) of the current user to that of the creator 
of the file whenever the file is executed as a program. This change in user ID 
is effective only during the execution of the program that calls for it. The 
set-user-ID 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-ID 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 ID of the invoker of any program is always available, 
set-user-ID 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 ``<B>.</B>'' and ``<B>..</B>''. The command which creates a 
directory is owned by the super-user and has the set-user-ID bit set. After it 
checks its invoker's authorization to create the specified directory, it creates 
it and makes the entries for ``<B>.</B>'' and ``<B>..</B>''. </P>
<P>Because anyone may set the set-user-ID bit on one of his own files, this 
mechanism is generally available without administrative intervention. For 
example, this protection scheme easily solves the MOO accounting problem posed 
by ``Aleph-null.'' [8] </P>
<P>The system recognizes one particular user ID (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. </P>
<H4>3.6 I/O calls </H4>
<P>The system calls to do I/O are designed to eliminate the differences between 
the various devices and styles of access. There is no distinction between 
``random'' and ``sequential'' I/O, nor is any logical record size imposed by the 
system. The size of an ordinary file is determined by the number of bytes 
written on it; no predetermination of the size of a file is necessary or 
possible. </P>
<P>To illustrate the essentials of I/O, some of the basic calls are summarized 
below in an anonymous language that will indicate the required parameters 
without getting into the underlying complexities. Each call to the system may 
potentially result in an error return, which for simplicity is not represented 
in the calling sequence. </P>
<P>To read or write a file assumed to exist already, it must be opened by the 
following call: 
<DL>
  <DT>
  <DD><TT><PRE>filep = open(name, flag)
</PRE></TT></DD></DL>where <I>name</I> indicates the name of the file. An 
arbitrary path name may be given. The <I>flag</I> argument indicates whether the 
file is to be read, written, or ``updated,'' that is, read and written 
simultaneously. 
<P></P>
<P>The returned value <I>filep</I> is called a <B>file descriptor</B>. It is a 
small integer used to identify the file in subsequent calls to read, write, or 
otherwise manipulate the file. </P>
<P>To create a new file or completely rewrite an old one, there is a 
<I>create</I> system call that creates the given file if it does not exist, or 
truncates it to zero length if it does exist; <I>create</I> also opens the new 
file for writing and, like <I>open</I>, returns a file descriptor. </P>
<P>The file system maintains no locks visible to the user, nor is there any 
restriction on the number of users who may have a file open for reading or 
writing. Although it is possible for the contents of a file to become scrambled 
when two users write on it simultaneously, in practice difficulties do not 
arise. We take the view that locks are neither necessary nor sufficient, in our 
environment, to prevent interference between users of the same file. They are 
unnecessary because we are not faced with large, single-file data bases 
maintained by independent processes. They are insufficient because locks in the 
ordinary sense, whereby one user is prevented from writing on a file that 
another user is reading, cannot prevent confusion when, for example, both users 
are editing a file with an editor that makes a copy of the file being edited. 
</P>
<P>There are, however, sufficient internal interlocks to maintain the logical 
consistency of the file system when two users engage simultaneously in 
activities such as writing on the same file, creating files in the same 
directory, or deleting each other's open files. </P>
<P>Except as indicated below, reading and writing are sequential. This means 
that if a particular byte in the file was the last byte written (or read), the 
next I/O call implicitly refers to the immediately following byte. For each open 
file there is a pointer, maintained inside the system, that indicates the next 
byte to be read or written. If <B>n</B> bytes are read or written, the pointer 
advances by <B>n</B> bytes. </P>
<P>Once a file is open, the following calls may be used: 
<DL>
  <DT>
  <DD><TT><PRE>n = read(filep, buffer, count)
n = write(filep, buffer, count)
</PRE></TT></DD></DL>Up to <I>count</I> bytes are transmitted between the file 
specified by <I>filep</I> and the byte array specified by <I>buffer</I>. The 
returned value <I>n</I> is the number of bytes actually transmitted. In the 
<I>write</I> case, <I>n</I> is the same as <I>count</I> except under exceptional 
conditions, such as I/O errors or end of physical medium on special files; in a 
<I>read</I>, however, <I>n</I> may without error be less than <I>count</I>. If 
the read pointer is so near the end of the file that reading <I>count</I> 
characters would cause reading beyond the end, only sufficient bytes are 
transmitted to reach the end of the file; also, typewriter-like terminals never 
return more than one line of input. When a <I>read</I> call returns with 
<I>n</I> equal to zero, the end of the file has been reached. For disk files 
this occurs when the read pointer becomes equal to the current size of the file. 
It is possible to generate an end-of-file from a terminal by use of an escape 
sequence that depends on the device used. 
<P></P>
<P>Bytes written affect only those parts of a file implied by the position of 
the write pointer and the count; no other part of the file is changed. If the 
last byte lies beyond the end of the file, the file is made to grow as needed. 
</P>
<P>To do random (direct-access) I/O it is only necessary to move the read or 
write pointer to the appropriate location in the file. 
<DL>
  <DT>
  <DD><TT><PRE>location = lseek(filep, offset, base)
</PRE></TT></DD></DL>The pointer associated with <I>filep</I> is moved to a 
position <I>offset</I> bytes from the beginning of the file, from the current 
position of the pointer, or from the end of the file, depending on <I>base.</I> 
<I>offset</I> may be negative. For some devices (e.g., paper tape and terminals) 
seek calls are ignored. The actual offset from the beginning of the file to 
which the pointer was moved is returned in <I>location</I>. 
<P></P>
<P>There are several additional system entries having to do with I/O and with 
the file system that will not be discussed. For example: close a file, get the 
status of a file, change the protection mode or the owner of a file, create a 
directory, make a link to an existing file, delete a file. </P>
<H4>IV. IMPLEMENTATION OF THE FILE SYSTEM </H4>
<P>As mentioned in Section 3.2 above, a directory entry contains only a name for 
the associated file and a pointer to the file itself. This pointer is an integer 
called the <B>i-number</B> (for index number) of the file. When the file is 
accessed, its i-number is used as an index into a system table (the 
<B>i-list</B>) stored in a known part of the device on which the directory 
resides. The entry found thereby (the file's <B>i-node</B>) contains the 
description of the file: </P>
<DL compact>
  <DT>i
  <DD>the user and group-ID of its owner 
  <DT>ii
  <DD>its protection bits 
  <DT>iii
  <DD>the physical disk or tape addresses for the file contents 
  <DT>iv
  <DD>its size 
  <DT>v
  <DD>time of creation, last use, and last modification 
  <DT>vi
  <DD>the number of links to the file, that is, the number of times it appears 
  in a directory 
  <DT>vii
  <DD>a code indicating whether the file is a directory, an ordinary file, or a 
  special file. </DD></DL><BR><BR>The purpose of an <I>open</I> or <I>create</I> 
system call is to turn the path name given by the user into an i-number by 
searching the explicitly or implicitly named directories. Once a file is open, 
its device, i-number, and read/write pointer are stored in a system table 
indexed by the file descriptor returned by the <I>open</I> or <I>create</I>. 
Thus, during a subsequent call to read or write the file, the descriptor may be 
easily related to the information necessary to access the file. 
<P>When a new file is created, an i-node is allocated for it and a directory 
entry is made that contains the name of the file and the i-node number. Making a 
link to an existing file involves creating a directory entry with the new name, 
copying the i-number from the original file entry, and incrementing the 
link-count field of the i-node. Removing (deleting) a file is done by 
decrementing the link-count of the i-node specified by its directory entry and 
erasing the directory entry. If the link-count drops to 0, any disk blocks in 
the file are freed and the i-node is de-allocated. </P>
<P>The space on all disks that contain a file system is divided into a number of 
512-byte blocks logically addressed from 0 up to a limit that depends on the 
device. There is space in the i-node of each file for 13 device addresses. For 
nonspecial files, the first 10 device addresses point at the first 10 blocks of 
the file. If the file is larger than 10 blocks, the 11 device address points to 
an indirect block containing up to 128 addresses of additional blocks in the