13.07.2015 Views

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

186 File Structures Chapter 6distinguished from all other files currently in storage.The physical representation of a file, usually on disk, must efficiently satisfy therequirements imposed by the chosen virtual form. We will discuss allocation on the disk,internal file structures, directories of files, and support for simultaneous use.1 NAMING STRUCTURE OF FILESThe purpose of a file name is to allow users and programs to refer to a particular file.File names can also relate to the contents or the intended use of a file. For example, auser might tell from the name of the file whether it contains a program in Fortran or Pascal.Every operating system has conventions for names. These conventions usuallydivide file names into parts that we will call components.Some operating systems (like Exec-8 for the Univac 1100) require every file nameto have exactly three components and each component to have an exact number of characters.Others (like recent versions of Unix) allow any number of components and placeno restriction on the number of characters. A fairly typical arrangement (found in Tops-10 for the DEC PDP-10 and in CP/M for many microcomputers) is to allow two components.The first component has six or eight characters and the second has three. Thefirst component may be picked at the whim of the programmer to designate the purposefor which the file has been written. The second component follows conventions that tellwhat sort of file it is.For example, suppose that the programmer wishes to build a Modula program thathas two modules. The program simulates an airport. The modules are Runway andPlane. The source program could be stored in files called runway.mod andplane.mod, respectively. The dot separates the components, and the mod componentindicates that the files are Modula source files. When the compiler has created objectfiles, they might be called runway.obj and plane.obj. Once the linker has combinedthese two files, the result might be an executable program calledsimulate.run. (If we are limited to six characters, we might be forced to call the filesimlat.run. One needs many more characters to avoid feeling constrained.) Theinput data for the program might be stored in simulate.dat, and the output createdby the program might be called simulate.out. If the program fails during execution,a copy of its address space might be saved for later debugging in a file calledsimulate.spc.Files are retrieved by full or partial specification of their file names. A partialspecification omits some of the components. It is very common to use the * character asa ‘‘wild-card’’ or ‘‘don’t care’’ entry in a file name. For example, *.obj refers to allfiles that have obj as their second component. The wild-card convention is usually notinterpreted by the file manager. Instead, programs that deal with files, such as the commandinterpreter (discussed in Chapter 7), convert a name with wild cards into a list offiles.In addition to listing all files with a particular component, a user often wishes tosee all files that pertain to some project or that belong to the same person. Various techniquesare available for imposing selective views on the file structure. All revolve

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!