- 1 Fundamental Concepts
- 2 File System API Calls in Windows 2000
- 3 Implementation of the Windows 2000 File System
11.7.2 File System API Calls in Windows 2000
The principal Win32 API functions for file management are listed in Fig. 11-1. There are actually many more, but these give a reasonable first impression of the basic ones. Let us now examine these calls briefly. CreateFile can be used to create a new file and return a handle to it. This API function must also be used to open existing files as there is no FileOpen API function. We have not listed the parameters for the API functions because they are so voluminous. As an example, CreateFile has seven parameters, which are roughly summarized as follows:
A pointer to the name of the file to create or open.
Flags telling whether the file can be read, written, or both.
Flags telling whether multiple processes can open the file at once.
A pointer to the security descriptor, telling who can access the file.
Flags telling what to do if the file exists/does not exist.
Flags dealing with attributes such as archiving, compression, etc.
The handle of a file whose attributes should be cloned for the new file.
Figure 11-1. The principal Win32 API functions for file I/O. The second column gives the nearest UNIX equivalent.
The next six API functions in Fig. 11-1 are fairly similar to the corresponding UNIX system calls. The last two allow a region of a file to be locked and unlocked to permit a process to get guaranteed mutual exclusion to it.
Using these API functions, it is possible to write a procedure to copy a file, analogous to the UNIX version of Fig. 6-5. Such a code fragment (without any error checking) is shown in Fig. 11-2. It has been designed to mimic our UNIX version. In practice, one would not have to program a copy file program since CopyFile is an API function (which executes something close to this program as a library procedure).
Figure 11-2. A program fragment for copying a file using the Windows 2000 API functions.
Windows 2000 NTFS is a hierarchical file system, similar to the UNIX file system. The separator between component names is \ however, instead of /, a fossil inherited from MS-DOS. There is a concept of a current working directory and path names can be relative or absolute. Hard and symbolic links are supported, the former implemented by having multiple directory entries, as in UNIX, and the latter implemented using reparse points (discussed later in this chapter). In addition, compression, encryption, and fault tolerance are also supported. These features and their implementations will be discussed later in this chapter.
The major directory management API functions are given in Fig. 11-3, again along with their nearest UNIX equivalents. The functions should be self explanatory.
Figure 11-3. The principal Win32 API functions for directory management. The second column gives the nearest UNIX equivalent, when one exists.