Given - Chapter 3 File Systems and File Hierarchy
Given - Chapter 3 File Systems and File Hierarchy
Programming
Chapter 3 File Systems and the File
Hierarchy
3.1 File System Abstraction
A file system is an abstraction that supports the creation, deletion,
and modification of les, and organization of files (les) into
directories. It also supports control of access to files and directories
and manages the disk space accorded to it.
We tend to use the phrase le system to refer to a hierarchical, tree-
like structure whose internal nodes are directories and whose
external nodes are non-directory-files (or perhaps empty directories),
but a le system is actually the at structure sitting on a linear storage
device such as a disk partition.
3.2 The Principal Components of a UNIX File System
Every file system has (at least) one superblock located at the
beginning of its allocated storage. The superblock contains all
of the information about how the file system is configured, such
as block size, block address range, and mount status. Copies of
the superblock are almost always stored in several other places
within a partition.
Each file system in UNIX has at least one table that identifies
the les in it. The entries in this table are called i-nodes
(pronounced eye-nodes), and the indices of the i-nodes in this i-
node table are called i-numbers. The i-nodes contain the le
attributes and a map indicating where the blocks of the le are
located on the disk.
Attributes include properties such as
the owner,
the group,
the permissions allowed on the le and the le type,
the number of links to the le
the time of last modification,
the time of last access,
the time the attributes were last changed,
the size in bytes of the le,
the number of blocks used by the le, and
the id
I-nodes and the tables that use them are important components of the UNIX le
system. Modern file systems usually have multiple i-node tables. Every file system
separates the i-node tables from the data blocks. The data blocks are where file
contents are stored.
How the Kernel Creates Files
Suppose that the current working directory is /home/sweiss/scratch, and the command
$ gcc -o testprog testprog.c is executed. Assuming that the program is compiled and
linked, and that I have write and execute permission for the directory
/home/sweiss/scratch, gcc will create the file named testprog in this directory.
This section answers the question, "What steps are taken by the kernel to create the file
testprog" on behalf of gcc? These steps can be outlined as follows:
1. The kernel creates an i-node for the le, if possible.
2. The kernel lls in the i-node with the le status.
3. The kernel allocates data blocks for the le and stores the le data in these blocks.
4. The kernel records the addresses of the data blocks in the i-node.
5. The kernel creates a directory entry in the scratch directory with the i-node
number and file name testprog.
3.3 Reading Directory Information:
getdents()
System call: int getdents( int fd, struct dirent* buf, int structSize )
reads the directory file with descriptor fd from its current position
and fills the structure pointed to be by buf with the next entry.
NAME MEANING
d_ino the inode number
d_off the offset of the next directory entry
d_reclen the length of the directory entry structure
d_nam the length of the filename
Miscellaneous File Management System Calls
NAME Function
- “chown()” and “fchown()” change the owner and/or group of a file and
work like this:
- Example, changed the group of the file “test.txt” from “music” to “cs”.
which has a group ID number of 62.
- “dup()”, “dup2()”
to duplicate file descriptors, and they work like this:
- the original and copied file descriptors share the same file pointer
and access mode.
- return the index of the new file descriptor if successful and a value of
-1 otherwise.
Duplicating a File Descriptor: dup() and dup2()
- I created a file called “test.txt” and wrote to it via four different file
descriptors: