An Operating Systems Vade Mecum

chapter 6FILE STRUCTURESIn Chapter 5, we described device control through the service calls Open, Close, Position,Read, Write, and Control. We also saw that files can serve as a unifying metaphor fordevices. In this chapter, we will look more carefully at files as objects in their own right.We will refer to the operating-system module that controls file access as the filemanager. In Figure 3.23, it would be depicted as a separate part of the kernel. When aprocess makes a file-related service call, the envelope task calls the file manager to dealwith it. In turn, the file manager may make several requests of the disk driver in order tocomplete its job. For example, a request to open a file might turn into several requests toread disk blocks to find where the file is on the disk.We define a file as a named collection of data. Once created, a file remains until itis destroyed, which can be seconds, days, or years later. The data in a file might be writtenby one process and later read by the same or different processes. We will also allowthe data in files to be appended, modified, or completely overwritten. In a sense, files arean extension of the virtual store of a process. However, their continued existence afterthe termination of that process and their availability to other processes makes them particularlyuseful for long-term storage of results. Files may be stored on practically anyread/write medium; disk storage is the most common, so we will concentrate on that.Our examination of files is divided into two major parts, the virtual and the physical.Files are abstractions built according to the Beautification Principle, both hiding andenhancing the underlying physical reality. The virtual notion of a file includes how it isnamed, how it is protected from unwanted access, its internal structure, how it can berecovered after accidental destruction, and how it behaves when more than one processwants to use it at the same time. Files are used for a wide variety of purposes, and theirvirtual forms depend on their purposes. Some operating systems provide different sortsof files with different properties for different applications. Other operating systemsattempt to provide one standard sort of file with properties powerful enough so thatalmost all applications can use it satisfactorily. For example, if a file is used only by theprocess that creates it, there may be no need to give that file a name. Any file that ismeant to be preserved after its creator terminates must have a name so that it can be185