Now we will consider some system calls that relate more to directories or the file system as a whole, rather than just to one particular file as in the previous section. The first two calls, mkdir and rmdir, create and remove empty directories, respectively. The next call is link. Its purpose is to allow the same file to appear under two or more names, often in different directories. A typical use is to allow various members of the same programming team to share a common file, with each of them having the file appear in his own directory, maybe under different names. Sharing a file is not the same as giving every team member a private copy; having a shared file means that changes that any member of the team makes are instantly visible to the other members - there is only one file. When copies are made of a file, subsequent changes made to one copy do not affect the others.
In order to see how link works, consider the situation of figure 1-(a). Here are two users, ast and jim, each having his own directory with some files. If ast now executes a program containing the system call
the file memo in jim's directory is now entered into ast's directory under the name note. Thereafter, /usr/jim/memo and /usr/ast/note refer to the same file. As an aside, whether user directories are kept in /usr, /user, /home, or somewhere else is just a decision made by the local system administrator.
Understanding how link works will possibly make it clearer what it does. Every file in UNIX has a unique number, its i-number, that identifies it. This i-number is an index into a table of i-nodes, one per file, telling who owns the file, where its disk blocks are, and so on. A directory is just a file containing a set of (i-number, ASCII name) pairs. In the first versions of UNIX, each directory entry was 16 bytes - 2 bytes for the i-number and 14 bytes for the name. Now a more complex structure is required to support long file names, but conceptually a directory is still a set of (i-number, ASCII name) pairs. In figure 1, mail has i-number 16, and so on. What link does is just create a new directory entry with a (maybe new) name, using the i-number of an existing file. In figure. 1-(b), two entries have the same i-number (70) and thus refer to the same file. If either one is later removed, using the unlink system call, the other one remains. If both are removed, UNIX 00sees that no entries to the file exist (a field in the i-node keeps track of the number of directory entries pointing to the file), so the file is removed from the disk.
As we have mentioned earlier, the mount system call allows two file systems to be merged into one. A common situation is to have the root file system containing the binary (executable) versions of the common commands and other heavily used files, on a hard disk. The user can then insert a CD-ROM disk with files to be read into the CD-ROM drive.
By executing the mount system call, the CD-ROM file system can be attached to the root file system, as shown in Fig. 2. A typical statement in C to perform the mount is
mount("/dev/fd0", "/mnt", 0);
where the first parameter is the name of a block special file for drive 0, the second parameter is the place in the tree where it is to be mounted, and the third parameter tells whether the file system is to be mounted read-write or read-only.
After the mount call, a file on drive 0 can be accessed by just using its path from the root directory or the working directory, without regard to which drive it is on. In reality, second, third, and fourth drives can also be mounted anywhere in the tree. The mount call makes it possible to combine removable media into a single integrated file hierarchy, without having to worry about which device a file is on. Though this example involves CD-ROMs, portions of hard disks (often called partitions or minor devices) can also be mounted this way, as well as external hard disks and USB sticks. When a file system is no longer required, it can be unmounted with the umount system call.
Tagssystem calls, file system, unix
- Soft Timers
- Error Handling
- EXAMPLE FILE SYSTEMS
- Defragmenting Disks
- File System Consistency
- File System Backups
- Implementing Directories
- FILE SYSTEM IMPLEMENTATION
- Backing Store
- MEMORY MANAGEMENT
- Message Passing
- Sleep and Wakeup
- Implementing Threads in the Kernel
- Process States
- Process Hierarchies
- Process Termination
- Process Creation
- METRIC UNITS / SUMMARY
- OUTLINE OF THE REST OF THIS BLOG
- The Model of Run Time
- OPERATING SYSTEM STRUCTURE
- The Windows Win32 API
- Miscellaneous System Calls
- System Calls for File Management
- System Calls for Process Management
- SYSTEM CALLS
- Hard Disks
- The Shell
- The Third Generation (1965-1980) ICs and Multiprogramming