`
`3"
`E
`
`
`
`?..=,..:,.._,..._.‘....M..uA
`
`1wa 94' CROSSROADS EXHIBIT 2056
`
`
`Oracle Corp., et a! v. Crossroads Systems, Inc.
`|PR2014-01207 and |PR2014-1209
`
`

`

`Other bestselling titles by Andrew S. Tanenbaum
`Structured Computer Organization, 5th edition
`now in its fifth edition, provides the ideal introduction to
`This widely read
`computer architecture. It covers the topic in an easy-ta-understand way, bottom
`up. There is a chapter on digital logic for beginners, followed by chapters on
`microarchitecture, the instruction set architecture level, operating systems, assem-
`bly language, and parallel computer architectures.
`Computer Networks, 4th edition
`This best seHer, curre;tly in its fourth edition, provides the ideal introduction to
`today's and tomorrow's networks. It explains in detail how modem networks are
`structured. Starting with the physical layer and working up to the application
`layer, the book covers a vast number of important topics, including wireless com-
`munication, fiber optics, data link protocols, Ethernet, routing algorithms, network
`perfonnance, security, DNS, electronic mail, the World Wide Web, and mul-
`timedia. The book has especially thorough coverage ofTCPIIP and the Internet.
`Operating Systems: Design and Implementation, 3rd edition
`This popular text on operating systems is the only book covering both the princi-
`ples of operating systems and their application to a real system. All the traditional
`operating systems topics are covered in detail. In addition, the principles are care-
`fully illustrated with MINIX, a free POSIX-based UNIX-like operating system for
`personal computers. Each book contains a free CD-ROM containing the complete
`MINIX system, including all the source code. The source code is listed in an
`appendix to the book and explained in detail in the text.
`
`Distributed Operating Systems, 2nd edition
`This text covers the fundamental concepts of distributed operating systems. Key
`topicS include communication and synchronization, processes and processors, dis-
`tributed shared memory, distributed file systems, and distributed real-time sys-
`tems. The principles are illustrated using four chapter-long examples: distributed
`object-based systems, distributed file systems, distributed Web-based systems,
`and distributed coordination-based systems.
`
`MODERN
`OPERATING SYSTEMS
`THIRD EDITION
`
`ANDREW S. TANENBAUM
`Vrije Universiteit
`Amsterdam, The Netherlands
`
`PEARSON EDUCATION INTERNATIONAL
`
`2 of 94
`
`

`

`To Suzanne, Barbara, Marvif!, and the memory of Bram and Sweetie It
`
`If you purchased this book within the United States or Canada you should be aware that it has been wrongfully imported without the
`approval of the Publisher or .the Author.
`
`Editoria! Director. Computer Sc:ience, Engineering, and Advanced Mathematics: Marcia J. HO/tan
`Executive Editor: Tracy Dunkelberger
`Editorial AssislUnl: Melinda Haggerry
`Associate Editor: ReeAlllle Dm,jes
`Senior Managing Editor:: Scal! DisawlO
`Production Editor: bwill Zucker
`Interior design: Andrew S. Tanenbaum
`Typesetting: Andrew S. TallenbawlI
`Au Director: Kenn), Beck
`Art Editor:: Gregol)" Dulles
`,
`Media Editor: David Alick
`Manufacturing Manager: Alan Fischer
`Manufacturing Buyer: Lisa McDowell
`Marketing Manager: Mack Patterson
`
`© 2009 Pearson Education, Inc.
`Pearson Prentice Hal!
`Pearson Education, Inc.
`Upper Saddle River, NJ 07458
`
`An rights reserved. No part of this book may be reproduced in any fonn or by any means, without pennission in writing from the
`publisher.
`
`Pearson Prentice HnU™ is a trademark of Pearson Education, Inc.
`The author and publisher of this book have used their best efforts in preparing this book. These efforts include the development,
`reseaf(;h, and testing of the theories and programs to detennine their effectiveness. The author and publisher make no warranty of any
`kind, e;o;pressed or implied, with regard to these programs or the documentation contained in this book. The author and publisher
`shaH not be liable in any event for incidental or consequential damages in connection with, or ariSing out of, the
`furnishing, perfonnance, or use of these progl1lms.
`
`I ,
`
`Printed in the United States of America
`10 9 8 7 6 5 4 3 2 I
`
`ISBN 0-13-813459-6
`978-0-13-813459-4
`
`Pearson Education Ltd., London
`Pearson Education Australia Pty. Ltd., Sydney
`Pearson Education Singapore, Pte. Ltd.
`Pearson Education North Asia Ltd., Hong Kong
`Pearson Education Canada, Inc., Toronto
`Pearson Educaci6n de Mexico, S.A. de C.v.
`Pearson Education-Japan, TO/..)"Q
`Pearson Education Malaysia, Pte. Ltd.
`Pearson Education, Inc., Upper Saddle River, New Jersey
`
`I j
`
`3 of 94
`
`

`

`252
`CHAP. 3
`MEMORY MANAGEMENT
`sembly language programming text. Note that doing this perfectly without additional
`information is, in general, an impossible task, because some data words may have
`values that mimic instruction object codes.
`42. Write a program that simulates a paging system using the aging algorithm. The num-
`ber of page frames is a parameter. The sequence of page references should be read
`from a file. For a given input file, plot the number of page faults per 1000 memory ref-
`erences as a function of the number of page frames available.
`43. Write a program that demonstrates the effect of TLB misses on the effective memory
`access time by measuring the per-access time it takes to stride through a large array.
`(a) Explain the main concepts behind the program, and describe what you expect the
`output to show for some practical virtual memory architecture.
`(b) Run the program on some computer and explain how well the data fit your expec-
`tations.
`(c) Repeat part (b) but for an older computer with a different architecture and explain
`any major differences in the output.
`44. Write a program that will demonstrate the difference between using a local page
`replacement policy and a global one for the simple case of two processes. You will
`need a routine that can generate a page reference string based on a statistical model.
`This model has N states numbered from 0 to N-l representing each of the possible
`page references and a probability P I associated with each state i representing the
`chance that the next reference is to the same page. Otherwise, the next page reference
`will be one of the other pages with equal probability.
`(a) Demonstrate that the page reference string generation routine behaves properly for
`some small N.
`(b) Compute the page fault rate for a small example in which there is one process and
`a fixed number of page frames. Explain why the behavior is correct.
`(c) Repeat part (b) with two processes with independent page reference sequences and
`twice as many page frames as in Part (b).
`(d) Repeat part (c) but using a global policy instead of a local one. Also, contrast the
`per-process page fault rate with that of the local policy approach.
`
`4
`
`FILE SYSTEMS
`
`a
`store andf :etrieve
`amount 0 mfOnnatlOn WIthllllts Own ad-
`dress s ace H
`is
`to the size of the virtual
`addrest
`s SIze IS adequate, but for others, such as
`airline reservations banki
`keeping, it is far too small.
`A second rOblem
`.ng, or
`a process' address space
`is that when
`process
`For many applications,
`(e.g., for
`the
`. n: or weeks, months, or even
`forever. Havmg it vanish when th
`is unacceptable.
`process usmg It
`Furthermore, it must not (TO away
`en a computer crash kills the process
`b]
`. e..
`A third
`£
`pro em IS that It IS frequently neces
`.
`] . ]
`cess (parts of) the infonnation at th
`.
`sary or mu tip e processes to ac-
`directory stored inside the address s
`tIIl!e. If we have an online telephone
`access it. The way to solve this
`onl? th.at
`can
`dent of anyone process.
`m orrnatlon Itself mdepen-
`Thus we have three essential requirements for long-tenn i-+"o
`.
`Hl' nnaUon storage:
`L It must be possible to store a very large amount of information.
`2. The infonnation must survive the termination of the process using it.
`3. Multiple processes must be able to access the infonnation concurrently.
`Magnetic disks have been used .£
`£ h'
`optical disks are also used but they
`and
`storage.
`hor] t IS
`,
`uc ower peuonnance. We wIll study
`
`253
`
`4 of 94
`
`

`

`CHAP. 4
`
`of a disk as a
`
`FILE SYSTEMS
`254
`sufficient to
`disks more in Chap. 5, but for the moment, it
`linear sequence of fixed-size blocks and supportmg two operatIOns:
`1. Read block k.
`2. Write block k
`In reality there are more, but with these two operations one could, in principle,
`solve the long-term storage problem.
`.
`.
`However, these are very inconvenient
`espeCially on large systems
`used by many applications and possibly multlple users (e.g., on a server). Just a
`few of the questions that quickly arise are:
`1. How do you find infonnation?
`2. How do you keep one user from reading another user's data?
`3. How do you know which blocks are free?
`and there are many more.
`Just as we saw how the operating system abstracted away the concept of the
`processor to create the abstraction of a process and how it abstracted away the
`can
`concept of physical memory to offer processes (virtual) address spaces,
`solve this problem with a new abstraction: the file. Together, the abstractlons of
`processes (and threads), address spaces, and files are the most important concepts
`relating to operating systems. If you really understand
`three
`from
`beginning to end, you are wen on your way to becommg an operatmg systems
`'11
`1
`expert.
`. k
`Files are 10llical units of information created by processes. A dIS WI usua-
`ly contains tho;sands or even millions of them, each one independent of the oth-
`ers. In fact if you think of each file as a kind of address space, you are not that
`far off,
`that they are used to model the disk instead modeling the
`Processes can read existing files and create new ones if need be. Info:matlOn
`stored in files must be persistent, that is, not be affected by process creatIon
`termination. A fIle should only disappear when its owner explicitly removes It.
`Although operations for reading and writing files are the most cornman ones,
`there exist many others, some of which we will examine below.
`Files are managed by the operating system. How they
`named,
`accessed, used, protected, implemented, and managed are major tOpICS 10 .operat-
`ing system design. As a whole, that part of the
`system dealing WIth files
`is known as the file system and is the subject of thIS chapter.
`.
`From the user's standpoint, the most important aspect of a file system IS how
`it appears, that is, what constitutes a file, how files are named and
`what
`operations are allowed on files, and so on. The details of whether hnked
`or
`bitmaps are used to keep track of free storage and how many sec.tors there are III a
`logical disk block are of no interest, although they are of great Importance to the
`
`255
`designers of the file system. For this reason, we have structured the chapter as
`several sections. The first two are concerned with the USer interface to files and
`directories, respectively. Then comes a detailed discussion of how the file system
`is implemented and managed. Finally, we give some examples of real file sys-
`tems.
`
`4.1 FILES
`In the following pages we will look at files from the user's point of view, that
`is, how they are used and what properties they have.
`4.1.1 File Naming
`Files are an abstraction mechanism. They provide a way to store information
`on the disk and read it back later. This must be done in such a way as to shield
`the user from the details of how and where the information is stored, and how the
`disks actually work.
`Probably the most important characteristic of any abstraction mechanism is
`the way the objects being managed are named, so we will start our examination of
`file systems with the subject of file naming. When a process creates a fire, it gives
`the file a name. When the process tenninates, the file continues to exist and can
`be accessed by other processes using its name.
`The exact rules for file naming vary somewhat from system to system, but all
`current operating systems anow strings of one to eight letters as legal file names.
`andrea, bruce, and cathy are possible file names. Frequently digits and spe-
`CIal characters are also permitted, so names like 2, urgent!, and Ffg.2-l4 are often
`valid as well. Many file systems support names as long as 255 characters.
`Some file systems distinguish between upper and lower case letters, whereas
`others do not. UNIX falls in the first category; MS-DOS falls in the second. Thus a
`UNIX system can have all of the following as three distinct files: maria, Maria,
`and MARIA. In MS-DOS, all these names refer to the same file.
`An aside on file systems is probably in order here. Windows 95 and Windows
`use the MS-DOS file system, called FAT-16, and thus inherit many of its
`98
`properttes, such as how file names are constructed. Windows 98 introduced some
`extensions to FAT-16, leading to FAT-32, but these two are quite similar. In ad-
`dition, Windows NT, Windows 2000, Windows XP, and .WV support both FAT
`file systems, which are really obsolete now. These four NT-based operating sys-
`tems have a native file system (NTFS) that has different properties (such as file
`names in Unicode). In this chapter, when we refer to the MS-DOS or FAT file
`systems, we mean FAT -16 and FAT -32 as used on Windows unless specified
`otherwise. We will discuss the FAT file systems later in this chapter and NTFS in
`Chap. 11, where we will examine Windows Vista in detail.
`
`5 of 94
`
`

`

`CHAP. 4
`256
`FILE SYSTEMS
`th: two parts sepa-
`Many operating systems support
`file names,
`rated by a period, as in prog.c. The part following the penod IS called the file
`extension and usually indicates something about the file. In MS-DOS, for ex-
`ample, file names are 1 to 8 characters, plus an optional extension of 1 to 3 char-
`'acters. In UNIX, the size of the extension, if any, is up to the user, and a ,fil: may
`even have two or more extensions, as in homepage.html.zip, where .html mdlcates
`a Web page in HTML and .zip indicates that the file (homepage.html)
`been
`compressed using the zip program. Some of the more common file extensIOns and
`their meanings are shown in Fig. 4-1.
`
`Extension
`file.bak
`file.c
`ffle.gif
`file.hlp
`We.html
`ffie.jpg
`file.mp3
`file.mpg
`1ile.o
`file.pdf
`file.ps
`file.tex
`file.txt
`file.zip
`
`Meaning
`
`Backup file
`C source program
`Compuserve Graphical Interchange Format image
`Help file
`World Wide Web HyperText Markup Language document
`Still picture encoded with the JPEG standard
`Music encoded in MPEG layer 3 audio fonnat
`Movie encoded with the MPEG standard
`Object file (compiler output, not yet Hnked)
`,Portable Document Format file
`PostScript f1!e
`Input for the TEX formatting program
`General text file
`Compressed archive
`
`Figure 4·L Some typical file extensions.
`
`are not
`In some systems (e.g., UNIX), file extensions are just. conventions
`enforced by the operating system. A file named file. txt ITIlght be some kind <:f text
`fIle but that name is more to remind the owner than to convey any actual mfor-
`to the computer. On the other hand, a C compiler may actually insist that
`files it is to compile end in .c, and it may refuse to compile them if they do not
`Conventions like this are especially useful. when the same program can handle
`several different kinds of files. The C compiler, for example, can be given a list of
`several files to compile and link together, some of them C files and some of them
`assembly language files. The extension then becomes
`for the compiler to
`tell which are C files, which are assembly files, and WhICh are other files.
`In contrast Windows is aware of the extensions and assigns meaning to them.
`Users (or proc;sses) can register extensions with the operating system and
`for each one which program «owns" that extension. When a user double clicks on
`
`SEC. 4.1
`
`FILES
`257
`a file name, the program assigned to its file extension is launched with the file as
`double clicking on file.doc starts Microsoft Word with
`parameter.
`file. doc as the lllitlal file to edit
`4.1.2 File Structure
`
`,Files .can ?e Structured in any of several ways. Three common possibilities are
`depIcted m hg, 4-2., The file in Fig. 4-2(a) is an unstructured sequence of bytes.
`In effect, the operatmg system does not know or care what is in the file. All it
`sees are bytes. Any meaning must be imposed by user-level programs. Both
`UNIX and Windows use this approach.
`1 Byte
`1 Record
`
`(a)
`
`Figure
`(c) Tree.
`
`(b)
`
`(e)
`Three kinds of files. (a) Byte sequence. (b) Record sequence.
`
`regard files as nothing more than byte sequences
`the
`pr0.vIdes the maxImum fleXIbIlity. User programs can put anything they Want in
`thel[ files and. name them any way that is convenient The operating system does
`help. but It also does not get in the way. For users who want to do unusual
`things, the
`can be very important. All versions of UNIX, MS-DOS, and Win-
`dows use thIS file modeL
`The frrst step up in structure is shown in Fig. 4-2(b). In this model, a file is a
`sequence of fixed-length records, each with some internal structure. Central to the
`idea of a file being a s.equence ?f records is the idea that the read operation returns
`one
`and the wnte operatlOn overwrites or appends one record. As a histori-
`cal
`m
`gone by, when the 8?-column punched card was king, many
`(mamframe) operatmg systems based theIr file systems on files consisting of 80-
`character records, in effect, card images. These systems also supported files of
`
`6 of 94
`
`

`

`258
`CHAP. 4
`FILE SYSTEMS
`132-character records, which were intended for the line printer (which in those
`days were big chain printers having 132 columns). Programs read input in units
`of 80 characters and wrote it in units of 132 characters, although the final 52 could
`be spaces, of course. No current general-purpose system uses this model as its
`primary file system any more, but back in the days of
`punched cards
`and 132-character line printer paper this was a common model on mainframe
`computers.
`The third kind of file structure is shown in Fig. 4-2(c). In this organization, a
`file consists of a tree of records, not necessarily a11 the same length, each con-
`taining a key field in a fixed position in the record. The tree is sorted on the key
`field, to allow rapid searching for a particular key.
`The basic operation here is not to get the "next" record, although that is also
`possible, but to get the record with a specific key. For the zoo file of Fig. 4-2(c),
`one could ask the system to get the record whose key is pony, for example, with-
`out worrying about its exact position in the file. Furthermore, new records can be
`added to the file, with the operating system, and not the user, deciding where to
`place them. This type of file is clearly quite different from the unstructured byte
`streams used in UNIX and Windows but is widely used on the large mainframe
`computers still used in some commercial data processing.
`4.1.3 File Types
`Many operating systems support several types of files. UNIX and Windows,
`for example, have regular files and directories. UNIX also has character and block
`special files. Regular files are the ones that contain user information. All the
`files of Fig. 4-2 are regular files. Directories are system files for maintaining the
`structure of the file system. We will study directories below. Character special
`files are related to input/output and used to model serial I/O devices, such as ter-
`minals, printers, and networks. Block special files are used to model disks. In
`this chapter we will be primarily interested in regular files.
`Regular files are generally either ASCn files or binary files. ASCn files con-
`sist of lines of text. In some systems each line is terminated by a camage return
`character. In others, the line feed character is used. Some systems (e.g., MS-
`DOS) use both. Lines need not all be of the same length.
`The great advantage of ASCII files is that they can be displayed and printed
`as is, and they can be edited with any text editor. Furthennore, if large numbers of
`programs use ASCII files for input and output, it is easy to connect the output of
`one program to the input of another, as in shell pipelines. (The interprocess
`plumbing is not any easier, but interpreting the infonnation certainly is if a stan-
`dard convention, such as ASCIL is used for expressing it)
`Other files are binary, which just means that they are not ASCn files. Listing
`them on the printer gives an incomprehensible listing full of random junk. Usual-
`ly, they have some internal structure known to programs that use them.
`
`SEC. 4.1
`
`FILES
`259
`in Fig. 4-3(a) We see a simple executable binary file taken from
`For
`an early verSIOn. of UNIX. Although technically the file is just a se uence of
`bhYtejjs, the
`system will only execute a file if it has the proper format
`It
`as lve sectIOns' header te t d
`I
`.
`.
`.
`.
`.
`,x, ata, re OcatIOn bIts, and symbol table The h d
`starts WIth a so-called rna . b'd"
`ea er
`.
`.
`gIc num er, 1 entlfymg the file as an executable file (to
`prevent the aCCIdental execution of a file not in this fonnat) Then co
`th
`.
`of the various piec
`f th fil
`h
`me e SIzes
`.
`. es 0
`e
`I e, t e address at which execution starts and some
`fl b'
`Its. F?llowmg the header are the text and data of the program
`These
`ag
`and relocated USing the relocation bits. The symbol table
`mto
`IS use
`lor debuggmg.
`
`/
`
`Module
`name
`
`Date
`
`Owner
`Protection
`
`Size
`
`Header
`
`Object
`module
`
`Header
`
`Object
`module
`
`Header
`
`Object
`module
`
`Text
`
`Data
`
`Relocation
`bits
`
`SYmbol
`table
`
`(a)
`
`(b)
`(a) An executable file. (b) An archive.
`Figure
`of a binary file is an archive, also from UNIX. It consists
`Our
`a collectIon of lIbrary
`(modules) compiled but not linked. Each one
`s prefaced by a header tellmg Its name, creation date, owner, protection code, and
`
`7 of 94
`
`

`

`260
`CHAP, 4
`FILE SYSTEMS
`size. Just as with the executable file., the module headers are full of binary num-
`bers. Copying them to the printer would produce complete gibberish.
`Every operating system must recognize at least one file type: its own ex-
`ecutable file, but some recognize more. The old TOPS-20 system (for the
`DECsystem 20) went so far as to examine the creation time of any file to be exe-
`cuted. Then it located the source file and saw if the source had been modified
`since the binary was made. If it had been, it automatically recompiled the source.
`In UNIX terms, the make program had been built into the shell. The file extensions
`were mandatory, so the operating system could tell which binary program was
`derived from which source.
`Having strongly typed files like this causes problems whenever the user does
`anything that the system designers did not expect. Consider, as an example, a sys-
`tem in which program output files have extension .dat (data files). If a user writes
`a program formatter that reads a .c file (C program), transforms it (e.g., by con-
`verting it to a standard indentation layout), and then writes the transformed file as
`output, the output file will be of type .dat. If the user tries to offer this to the C
`compiler to compile it, the system will refuse because it has the wrong extension.
`Attempts to copy file.dat to file.c will be rejected by the system as invalid (to pro-
`tect the user against mistakes).
`While this kind of "user friendliness" may help novices, it drives experienced
`users up the wall since they have to devote considerable effort to Circumventing
`the operating system's idea of what is reasonable and what is not.
`4.1.4 File Access
`Early operating systems provided only one kind of file access: sequential
`access. In these systems, a process could read all the bytes or records in a file in
`order, starting at the beginning, but could not skip around and read them out of
`order. Sequential files could be rewound, however, so they could be read as often
`as needed. Sequential files were convenient when the storage medium was mag-
`netic tape rather than disk.
`When disks came into use for storing files, it became possible to read the
`bytes or records of a file out of order, or to access records by key rather than by
`position. Files whose bytes or records can be read in any order are called random
`access files. They are required by many applications.
`Random access files are essential for many applications, for example, data-
`base systems. If an airline customer calls up and wants to reserve a seat on a par-
`ticular flight, the reservation program must be able to access the record for that
`flight without having to read the records for thousands of other flights first.
`Two methods can be used for specifying where to start reading. In the first
`one, every read operation gives the position in the file to start reading at. In the
`second one, a special operation, seek, is provided to set the current position. After
`a seek, the file can be read sequentially from the now-current position. The latter
`method is used in UNIX and Windows.
`
`FILES
`
`SEC. 4,1
`4.1.5 File Attributes
`E:ery file ?as a ?ame and its data. In addition, all operating systems associate
`WIt?
`file, fo: example, the date and time the file was last
`and the file s SIze. We WIll call these extra items the file's attributes
`Some people call them metadata. The list of attributes varies considerably
`system to system. The table of Fig. 4-4 shows some of the poss 'b']'"
`b
`th
`ones also
`. tN' .
`1 1 lues, ut 0 er
`eXlS .
`0 eXIstmg system has all of these, but each one is present in
`some system.
`
`261
`
`Attribute
`Protection
`Password
`Creator
`OWner
`Read-only flag
`Hidden flag
`System flag
`Archive flag
`ASClI/binary flag
`Random access flag
`Temporary flag
`Lock flags
`Record length
`Key position
`Key length
`Creation time
`TIme of last acCess
`Time of last change
`Current size
`Maximum size
`
`Meaning
`Who can access the file and in what way
`Password needed to access the me
`lD of the person who created the file
`Current owner
`o for read/write; 1 for read only
`o for nonnal; 1 for do not display in listings
`o for normal files; 1 for system file
`o for has been backed up; 1 for needs to be backed up
`o for ASCI! file; 1 for binary fi'le
`o for sequential access only; 1 for random access
`o for normal; 1 for delete file on process exit
`o for unlocked; nonzero for locked
`Number of bytes in a record
`Offset of the key within each record
`Number of bytes in the key field
`Date and time the file was created
`Date and time the file was last accessed
`Date and time the tHe was last changed
`NUmber of bytes in the file
`Number of bytes the file may grow to
`
`Figure 4-4. Some possible file attributes.
`
`. The first four attributes relate to the file's protection and tell who may access
`It and who may not. All kinds of schemes are possible, some of which we will
`later. In some systems the user must present a password to aCcess a file in
`whIch case the password must be one of the attributes.
`'
`. The flags are bits or short fields that control or enable some specific property.
`Hidden files, for example, do not appear in listings of all the files. The archive
`
`8 of 94
`
`

`

`CHAP. 4
`
`262
`FILE SYSTEMS
`flag is a bit that keeps track of whether the file has been backed up recently. The
`backup program clears it, and the operating system sets it whenever a file is
`changed In this way, the backup program can tell which files need backing up.
`The temporary flag allows a file to be marked for automatic deletion when the
`process that created it terminates.
`The record length, key position, and key length fields are only present in files
`whose records can be looked up using a key. They provide the infonnation re-
`quired to find the keys.
`The various times keep track of when the file was created, most recently ac-
`cessed, and most recently modified. These are useful for a variety of purposes.
`For example, a source file that has been modified after the creation of the corres-
`ponding object file needs to be recompiled. These fields provide the necessary
`information.
`The current size tells how big the file is at present. Some old mainframe oper-
`ating systems require the maximum size to be specified when the file is created, in
`order to let the operating system reserve the maximum amount of storage in ad-
`vance. Workstation and personal computer operating systems are clever enough to
`do without this feature.
`4.1.6 File Operations
`Files exist to store information and allow it to be retrieved later. Different sys-
`tems provide different operations to anow storage and retrieval. Below is a dis-
`cussion of the most common system calls relating to files.
`1. Create. The file is created with no data. The purpose of the call is to
`announce that the file is coming and to set some of the attributes.
`2. Delete. When the file is no longer needed, it has to be deleted to free
`up disk space. There is always a system call for this purpose.
`3. Open. Before using a file, a process must open it. The purpose of the
`open call is to allow the system to fetch the attributes and list of disk
`addresses into main memory for rapid access on later calls.
`4. Close. When all the accesses are finished, the attributes and disk ad-
`dresses are no longer needed, so the file should be closed to free up
`internal table space. Many systems encourage this by imposing a
`maximum number of open files on processes. A disk is written in
`blocks, and closing a file forces writing of the file's last block, even
`though that block may not be entirely full yet.
`S. Read. Data are read from file. Usually, the bytes come from the CUf-
`rent position. The caller must specify how many data are needed and
`must also provide a buffer to put them in.
`
`263
`
`SEC 4.1
`6.
`
`FILES
`Data are written to the file again, usually at the current posi-
`If the current
`is the end of the file, the file's size
`current posItion is in the middle of the file, existing
`Increases. If
`data are overwntten and lost forever.
`7. Append. This call is a restricted form of write. It can only add data
`to the end of the file. Systems that provide a minimal set of system
`caIls do not
`have append, but many systems provide multi-
`ple ways of domg the same thing, and these systems sometimes have
`append.
`S. Seek. For random access files, a method is needed to specify from
`where to
`the data.
`COmmon approach is a system call, seek,
`reposItIOns the fil.e pomter to a specific place in the file. After
`thIS.
`has completed, data can be read from, or written to that
`posItIOn.
`'
`9. Get attributes. Processes often need to read file attributes to do thei
`work. For example the UNIX k '
`r
`rna e program IS commonly used to
`,
`manage software development projects consisting of many Source
`files. When make is called, it examines the modification times of all
`the
`and
`files .and arranges for the minimum number of
`compIlations
`to bnng everything up to date. To do itsjob, it
`must look at the attnbutes, namely, the modification times.
`10. Set attributes. Some of the attributes are user settable and can be
`chan.ged after the file .has been created. This system call makes that
`pOSSIble. The protection mode infonnation is an obvious example.
`Most of the flags also faU in this category.
`11. Rename: !t frequently happens that a user needs to change the name
`of an
`file. This system call makes that possible. It is not al-
`ways
`necessary, because the file can usually be copied to a
`new file WIth the new name, and the old file then deleted.
`
`4.1.7 An Example Program Using File System Calls
`this section we will examine a simple UNIX proo-ram that copies one file
`from Its source file to a destination file It is listed in Fig 45Th
`minimal functionality and even worse "error reporting b ·t .-,.'.
`e program has
`. de
`f h
`f h
`' U I gIves a reasonable
`1 a 0
`ow some 0
`t e system calls related to files work
`.'
`The program, copyJi-le, can be called, for example, by' the command line
`copyfile abc xyz
`to copy the file abc to xyz. If xyz already exists, it will be overwritten. Otherwise,
`
`9 of 94
`
`

`

`264
`
`FILE SYSTEMS
`
`CHAP. 4
`
`1* File copy program. Error checking and reporting is minimal. */
`1* include necessary header files */
`
`#include <sysltypes.h:>
`#include <fcntLh>
`#include <stdlib.h>
`#include <unistd.h>
`int main(!nt argc, char *argvO);
`
`#define BUF _SIZE 4096
`#deflne OUTPUT _MODE 0700
`
`/* ANSI prototype */
`/* use a buffer size of 4096 bytes */
`{* protection bits for output file */
`