1 .\" This module is believed to contain source code proprietary to AT&T.
2 .\" Use and redistribution is subject to the Berkeley Software License
3 .\" Agreement and your Software Agreement with AT&T (Western Electric).
5 .\" @(#)p1 8.1 (Berkeley) 6/8/93
8 .OH 'The UNIX Time-Sharing System''PSD:1-%'
9 .EH 'PSD:1-%''The UNIX Time-Sharing System'
16 Time-Sharing System\f1\s10\v'-.2n'*\v'.2n'\s0\fP
18 D. M. Ritchie and K. Thompson
22 Association for Computing Machinery, Inc.,
23 reprinted by permission.
24 This is a revised version of an article
25 that appeared in Communications of the \*sACM\*n,
27 No. 7 (July 1974), pp. 365-375.
29 revised version of a paper presented
30 at the Fourth \*sACM\*n Symposium on Operating
32 \*sIBM\*n Thomas J. Watson Research Center,
38 is a general-purpose, multi-user, interactive
39 operating system for the larger Digital Equipment Corporation
41 the Interdata 8/32 computers.
42 It offers a number of features
43 seldom found even in larger operating
46 A hierarchical file system incorporating
49 Compatible file, device, and inter-process I/O,
51 The ability to initiate asynchronous processes,
53 System command language selectable on a per-user basis,
55 Over 100 subsystems including a dozen languages,
57 High degree of portability.
59 This paper discusses the nature
60 and implementation of the file system
61 and of the user command interface.
66 There have been four versions of
71 The earliest (circa 1969-70) ran on
72 the Digital Equipment Corporation \*sPDP\*n-7 and -9 computers.
73 The second version ran on the unprotected
74 \*sPDP\*n-11/20 computer.
75 The third incorporated multiprogramming and ran
76 on the \*sPDP\*n-11/34, /40, /45, /60, and /70 computers;
77 it is the one described in the previously published version
78 of this paper, and is also the most widely used today.
80 This paper describes only the
82 system that runs on the \*sPDP\*n-11/70 and the
83 Interdata 8/32 computers.
84 In fact, the differences among the various systems is
86 most of the revisions made to the originally published version of this
88 aside from those concerned with style,
89 had to do with details of the implementation of the file system.
96 over 600 installations have been put into service.
97 Most of them are engaged in applications such as
98 computer science education,
99 the preparation and formatting of documents
100 and other textual material,
101 the collection and processing of trouble data
102 from various switching machines within the Bell System,
103 and recording and checking telephone service
105 Our own installation is used mainly for research
106 in operating systems, languages,
108 and other topics in computer science, and also for
109 document preparation.
111 Perhaps the most important achievement of
115 a powerful operating system for interactive use
116 need not be expensive either in equipment or in human
119 can run on hardware costing as little as $40,000, and
120 less than two man-years were spent on the main system
122 We hope, however, that users find
124 most important characteristics of the system
125 are its simplicity, elegance, and ease of use.
127 Besides the operating system proper, some major programs
134 Text editor based on \*sQED\*n
138 Assembler, linking loader, symbolic debugger
139 Phototypesetting and equation setting programs
141 cherry kernighan typesetting mathematics cacm
144 kernighan lesk ossanna document preparation bstj
151 Dozens of languages including
152 Fortran 77, Basic, Snobol, \*sAPL\*n, Algol 68, M6, \*sTMG\*n, Pascal
156 There is a host of maintenance, utility, recreation and novelty programs,
160 user community, which numbers in the thousands,
161 has contributed many more programs and languages.
162 It is worth noting that the system is totally self-supporting.
165 software is maintained on
168 likewise, this paper and all other
171 were generated and formatted by the
173 editor and text formatting
176 II. HARDWARE AND SOFTWARE ENVIRONMENT
178 The \*sPDP\*n-11/70 on which the Research
180 system is installed is a 16-bit
181 word (8-bit byte) computer with 768K bytes of core memory;
184 about equally divided between code
186 This system, however, includes a very large number of
188 and enjoys a generous allotment
189 of space for I/O buffers and system tables;
190 a minimal system capable of running the software
192 require as little as 96K bytes
194 There are even larger installations;
195 see the description of the
196 \*sPWB/UNIX\*n systems,
198 dolotta mashey workbench software engineering
201 dolotta haight mashey workbench bstj
205 There are also much smaller, though somewhat restricted,
206 versions of the system.
208 lycklama microprocessor bstj
212 Our own \*sPDP\*n-11 has two
213 200-Mb moving-head disks
214 for file system storage and swapping.
215 There are 20 variable-speed
216 communications interfaces
217 attached to 300- and 1200-baud data sets,
218 and an additional 12 communication lines
219 hard-wired to 9600-baud terminals and
221 There are also several 2400- and 4800-baud
222 synchronous communication interfaces
223 used for machine-to-machine file transfer.
224 Finally, there is a variety
227 nine-track magnetic tape,
231 a digital switching network,
236 software is written in the
237 abovementioned C language.
239 c programming language kernighan ritchie prentice-hall
241 Early versions of the operating system were written in assembly language,
242 but during the summer of 1973, it was rewritten in C.
243 The size of the new system was about one-third greater
244 than that of the old.
245 Since the new system not only became much easier to
246 understand and to modify but also
248 many functional improvements,
249 including multiprogramming and the ability to
250 share reentrant code among several user programs,
251 we consider this increase in size quite acceptable.
255 The most important role of
259 From the point of view of the user, there
260 are three kinds of files: ordinary disk files,
261 directories, and special files.
266 contains whatever information the user places on it,
267 for example, symbolic or binary
269 No particular structuring is expected by the system.
270 A file of text consists simply of a string
271 of characters, with lines demarcated by the newline character.
272 Binary programs are sequences of words as
273 they will appear in core memory when the program
275 A few user programs manipulate files with more
277 for example, the assembler generates, and the loader
278 expects, an object file in a particular format.
280 the structure of files is controlled by
281 the programs that use them, not by the system.
286 the mapping between the names of files
287 and the files themselves, and thus
288 induce a structure on the file system as a whole.
289 Each user has a directory of his own files;
290 he may also create subdirectories to contain
291 groups of files conveniently treated together.
292 A directory behaves exactly like an ordinary file except that it
293 cannot be written on by unprivileged programs, so that the system
294 controls the contents of directories.
296 appropriate permission may read a directory just like any other file.
298 The system maintains several directories
303 All files in the system can be found by tracing
304 a path through a chain of directories
305 until the desired file is reached.
306 The starting point for such searches is often the
308 Other system directories contain all the programs provided
309 for general use; that is, all the
311 As will be seen, however, it is by no means necessary
312 that a program reside in one of these directories for it
315 Files are named by sequences of 14 or
317 When the name of a file is specified to the
318 system, it may be in the form of a
322 is a sequence of directory names separated by slashes, ``/\^'',
323 and ending in a file name.
324 If the sequence begins with a slash, the search begins in the
327 .UL /alpha/beta/gamma
328 causes the system to search
329 the root for directory
340 may be an ordinary file, a directory, or a special
342 As a limiting case, the name ``/\^'' refers to the root itself.
344 A path name not starting with ``/\^'' causes the system to begin the
345 search in the user's current directory.
348 specifies the file named
355 The simplest kind of name, for example,
357 refers to a file that itself is found in the current
359 As another limiting case, the null file name refers
360 to the current directory.
362 The same non-directory file may appear in several directories under
363 possibly different names.
364 This feature is called
366 a directory entry for a file is sometimes called a link.
370 differs from other systems in which linking is permitted
371 in that all links to a file have equal status.
372 That is, a file does not exist within a particular directory;
373 the directory entry for a file consists merely
374 of its name and a pointer to the information actually
376 Thus a file exists independently of any
377 directory entry, although in practice a file is made to
378 disappear along with the last link to it.
380 Each directory always has at least two entries.
382 ``\|\fB.\|\fP'' in each directory refers to the directory itself.
384 may read the current directory under the name ``\fB\|.\|\fP'' without knowing
385 its complete path name.
386 The name ``\fB\|.\|.\|\fP'' by convention refers to the parent of the
387 directory in which it appears, that is, to the directory in which
390 The directory structure is constrained to have the form
392 Except for the special entries ``\|\fB\|.\|\fP'' and ``\fB\|.\|.\|\fP'', each directory
393 must appear as an entry in exactly one other directory, which is its
395 The reason for this is to simplify the writing of programs
396 that visit subtrees of the directory structure, and more
397 important, to avoid the separation of portions of the hierarchy.
398 If arbitrary links to directories were permitted, it would
399 be quite difficult to detect when the last connection from
400 the root to a directory was severed.
404 Special files constitute the most unusual feature of the
407 Each supported I/O device
408 is associated with at least one such file.
409 Special files are read and written just like ordinary
410 disk files, but requests to read or write result in activation of the associated
412 An entry for each special file resides in directory
414 although a link may be made to one of these files
415 just as it may to an ordinary file.
417 to write on a magnetic tape
418 one may write on the file
420 Special files exist for each communication line, each disk,
422 and for physical main memory.
425 and the memory special file are protected from
426 indiscriminate access.
428 There is a threefold advantage in treating
429 I/O devices this way:
431 are as similar as possible;
432 file and device names have the same
433 syntax and meaning, so that
434 a program expecting a file name
435 as a parameter can be passed a device
437 special files are subject to the same
438 protection mechanism as regular files.
440 3.4 Removable file systems
442 Although the root of the file system is always stored on the same
444 it is not necessary that the entire file system hierarchy
445 reside on this device.
448 system request with two arguments:
449 the name of an existing ordinary file, and the name of a special
450 file whose associated
451 storage volume (e.g., a disk pack) should have the structure
452 of an independent file system
453 containing its own directory hierarchy.
457 references to the heretofore ordinary file
458 to refer instead to the root directory
459 of the file system on the removable volume.
462 replaces a leaf of the hierarchy tree (the ordinary file)
463 by a whole new subtree (the hierarchy stored on the
467 there is virtually no distinction
468 between files on the removable volume and those in the
469 permanent file system.
470 In our installation, for example,
471 the root directory resides
472 on a small partition of one of
474 while the other drive,
475 which contains the user's files,
476 is mounted by the system initialization
478 A mountable file system is generated by
479 writing on its corresponding special file.
480 A utility program is available to create
481 an empty file system,
482 or one may simply copy an existing file system.
484 There is only one exception to the rule of identical
485 treatment of files on different devices:
486 no link may exist between one file system hierarchy and
488 This restriction is enforced so as to avoid
489 the elaborate bookkeeping
490 that would otherwise be required to assure removal of the links
491 whenever the removable volume is dismounted.
495 Although the access control scheme
496 is quite simple, it has some unusual features.
497 Each user of the system is assigned a unique
498 user identification number.
499 When a file is created, it is marked with
500 the user \*sID\*n of its owner.
501 Also given for new files
502 is a set of ten protection bits.
503 Nine of these specify
504 independently read, write, and execute permission
507 for other members of his group,
508 and for all remaining users.
510 If the tenth bit is on, the system
511 will temporarily change the user identification
512 (hereafter, user \*sID\*n)
513 of the current user to that of the creator of the file whenever
514 the file is executed as a program.
515 This change in user \*sID\*n is effective only
516 during the execution of the program that calls for it.
517 The set-user-\*sID\*n feature provides
518 for privileged programs that may use files
519 inaccessible to other users.
520 For example, a program may keep an accounting file
521 that should neither be read nor changed
522 except by the program itself.
523 If the set-user-\*sID\*n bit is on for the
524 program, it may access the file although
525 this access might be forbidden to other programs
526 invoked by the given program's user.
527 Since the actual user \*sID\*n
528 of the invoker of any program
530 set-user-\*sID\*n programs
531 may take any measures desired to satisfy themselves
532 as to their invoker's credentials.
533 This mechanism is used to allow users to execute
534 the carefully written
536 that call privileged system entries.
537 For example, there is a system entry
538 invokable only by the ``super-user'' (below)
541 As indicated above, directories are expected to
542 have entries for ``\fB\|.\|\fP'' and ``\fB\|.\|.\|\fP''.
543 The command which creates a directory
544 is owned by the super-user
545 and has the set-user-\*sID\*n bit set.
546 After it checks its invoker's authorization to
547 create the specified directory,
548 it creates it and makes the entries
549 for ``\fB\|.\|\fP'' and ``\fB\|.\|.\|\fP''.
551 Because anyone may set the set-user-\*sID\*n
552 bit on one of his own files,
553 this mechanism is generally
554 available without administrative intervention.
556 this protection scheme easily solves the \*sMOO\*n
557 accounting problem posed by ``Aleph-null.''
559 aleph null software practice
562 The system recognizes one particular user \*sID\*n (that of the ``super-user'') as
563 exempt from the usual constraints on file access; thus (for example),
564 programs may be written to dump and reload the file
566 unwanted interference from the protection