Classic Shell Scripting - Arnold Robbins [233]
All other files in Unix can be considered binary files: each of the bytes contained therein may take on any of 256 possible values. Text files are thus a subset of binary files.
Unlike some other operating systems, no character is foolishly usurped to mark end-of-file: the Unix filesystem simply keeps a count of the number of bytes in the file.
Attempts to read beyond the file byte count return an end-of-file indication, so it is not possible to see any previous contents of disk blocks.
Some operating systems forbid empty files, but Unix does not. Sometimes, it is the existence of a file, rather than its contents, that matters. Timestamps, file locks, and warnings such as THIS-PROGRAM-IS-OBSOLETE are examples of useful empty files.
The Unix files-as-byte-streams view has encouraged operating-system designers to implement file-like views of data that conventionally are not thought of as files. Several Unix flavors implement a process information pseudofilesystem: try man proc to see what your system offers. We discuss it in more detail in Section 13.7. Files in the /proc tree are not files on mass storage but rather, views into the process tables and memory space of running processes, or into information known to the operating system, such as details of the processor, network, memory, and disk systems.
For example, on one of the systems used to write this book, we can find out storage device details like this (the meaning of the slashes in the command argument is discussed in the next section):
$ cat /proc/scsi/scsi
Show disk device information
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: DMVS18V Rev: 0077
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 01 Lun: 00
Vendor: TOSHIBA Model: CD-ROM XM-6401TA Rev: 1009
Type: CD-ROM ANSI SCSI revision: 02
* * *
[9] See the interesting article by Barton P. Miller, Lars Fredriksen, and Bryan So, An Empirical Study of the Reliability of UNIX Utilities, Comm. ACM 33(12), 32-44, December 1990, ISSN 0001-0782, and its 1995 and 2001 follow-up technical reports. Both are available, together with their associated test software, at ftp://ftp.cs.wisc.edu/pub/paradyn/fuzz/ and ftp://ftp.cs.wisc.edu/pub/paradyn/technical_papers/fuzz*. The 2001 work extends the testing to the various Microsoft Windows operating systems.
[10] Available at http://www.math.utah.edu/pub/dosmacux/.
The Unix Hierarchical Filesystem
Large collections of files bring the risk of filename collisions, and even with unique names, make management difficult. Unix handles this by permitting files to be grouped into directories: each directory forms its own little name space, independent of all other directories. Directories can also supply default attributes for files, a topic that we discuss briefly in Section B.6.1, later in this Appendix.
Filesystem Structure
Directories can be nested almost arbitrarily deep, so the Unix filesystem forms a tree structure. Unix avoids the synonym folder because paper file folders do not nest. The base of the filesystem tree is called the root directory, and is given a special and simple name: / (ASCII slash). The name /myfile then refers to a file named myfile in the root directory. Slash also serves another purpose: it acts as a delimiter between names to record directory nesting. Figure B-1 shows a tiny portion of the top-level structure of the filesystem.
Figure B-1. Filesystem tree
Unix directories can contain arbitrary numbers of files. However, most current Unix filesystem designs, and filesystem programming interfaces, assume that directories are searched sequentially, so the time to find a file in a large directory is proportional to the number of files in that directory, even though much faster lookup schemes are known. If a directory contains more than a few hundred files, it is probably time to reorganize it into subdirectories.