These provided the most basic of interfaces with: More coordination such as device allocation and deallocation required the addition of: As file systems provided more services, more interfaces were defined: As additional file system types, hierarchy structure and supported media increased, additional features needed some specialized functions: Multi-user systems required APIs for: Writing user data to a file system is provided for use directly by the user program or the run-time library.
The run-time library for some programming languages may provide type conversion, formatting and blocking.
This operation is sometimes called PUT or PUTX (if the record exists) Reading user data, sometimes called GET, may include a direction (forward or reverse) or in the case of a keyed file system, a specific key.
The open API may be explicitly requested or implicitly invoked upon the issuance of the first operation by a process on an object.
It may cause the mounting of removable media, establishing a connection to another host and validating the location and accessibility of the object.
Depending on the programming language, additional specifications in the open may establish the modules to handle these conditions.
Some languages simply return a code indicating the type of failure which always must be checked by the program, which decides what to report and if it can continue.
Close may cause dismounting or ejecting removable media and updating library and file system structures to indicate that the object is no longer in use.
Incomplete structures or other inconsistencies may be caused by device or media errors, inadequate time between detection of impending loss of power and actual power loss, improper system shutdown or media removal, and on very rare occasions file system coding errors.
There is a variation of this scheme used in MS-DOS (DOS 4.0 onward) and compatibles to support CD-ROM and network file systems.
Instead of adding code to the kernel, as in the old scheme, or using kernel facilities as in the kernel-based scheme, it traps all calls to a file and identifies if it should be redirected to the kernel's equivalent function or if it has to be handled by the specific filesystem driver, and the filesystem driver "directly" access the disk contents using low-level BIOS functions.
The API is in the user space when the filesystem does not directly use kernel facilities but accesses disks using high-level operating system functions and provides functions in a library that a series of utilities use to access the filesystem.
There also exists a project that uses a Windows NT IFS driver for making NTFS work under Linux.