Filesystem API
From Wikipedia, the free encyclopedia
 |
To comply with Wikipedia's quality standards, this article may need to be rewritten. Please help improve this article. The discussion page may contain suggestions. |
 |
The factual accuracy of this article is disputed. Please see the relevant discussion on the talk page. (March 2008) |
A file system API is an application programming interface through which an operating system interfaces with file system code. The operating system usually provides abstractions for accessing different file systems transparently to userland programs, and in this sense it is analogous to device driver APIs that provide abstracted access to hardware.
Some file system APIs may also include interfaces for maintenance operations, such as creating or initializing a file system, verifying the file system for integrity, and defragmentation – although these are more often implemented independently from the file system code.
Microsoft Windows NT, 2000, and XP have a default file system API known as a file system driver for the NTFS, FAT and FAT32 file systems.
Contents |
[edit] History
Originally, operating systems were capable of handling only a disk filesystem, but as systems expanded two problems arose:
- Network shares were required to appear to the user as local disks.
- Users wanted to exchange files with other users that might be running another operating system.
In the old scheme, all filesystems and network protocols are specific to the operating system's kernel and when the user tried to access a file, it was the kernel that knew how the filesystem or network protocol worked.[citation needed]
This scheme means that adding support for a filesystem requires a major kernel rewrite. This isn't very efficient, so operating systems designers thought about separating the specific filesystem code from the file and network handling code of the kernel, and filesystem APIs resulted.
[edit] Kernel-level API
The API is "kernel-level" when the kernel not only provides the interfaces for the filesystems developers but is also the space in which the filesystem code reside.
It differs with the old schema in that the kernel itself uses its own facilities to talk with the filesystem driver and vice-versa, as contrary to the kernel being the one that handles the filesystem layout and the filesystem the one that directly access the hardware.
It isn't the cleanest scheme but resolves the difficulties of major rewrite that has the old scheme.
With modular kernels it allows adding filesystems as any kernel module, even third party ones. With non-modular kernels however it requires the kernel to be recompiled with the new filesystem code (and in closed-source kernels, this makes third party filesystem impossible).
Unixes and Unix-like systems such as Linux have used this scheme.
There is a variation of this scheme used in MS-DOS (DOS 4.0 onward) and compatibles to support CD-ROM and network filesystems. 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.
[edit] Driver-based API
The API is "driver-based" when the kernel provides facilities but the filesystem code resides totally external to the kernel (not even as a module of a modular kernel).
It is a cleaner scheme as the filesystem code is totally independent, it allows filesystems to be created for closed-source kernels and online filesystem additions or removals from the system.
Examples of this scheme are the Windows NT and OS/2 respective IFSs.
[edit] Mixed kernel-driver-based API
In this API all filesystems are in the kernel, like in kernel-based APIs, but they are automatically trapped by another API, that is driver-based, by the OS.
This scheme was used in Windows 3.1 for providing a FAT filesystem driver in 32-bit protected mode, and cached, (VFAT) that bypassed the DOS FAT driver in the kernel (MSDOS.SYS) completely, and later in the Windows 9x series (95, 98 and Me) for VFAT, the ISO9660 filesystem driver (along with Joliet), network shares, and third party filesystem drivers, as well as adding to the original DOS APIs the LFN API (that IFS drivers can not only intercept the already existent DOS file APIs but also add new ones from within the 32-bit protected mode executable).
However that API was not completely documented, and third parties found themselves in a "make-it-by-yourself" scenario even worse than with kernel-based APIs.
[edit] User space API
The API is in the user space when the filesystem doesn't 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.
This is useful for handling disk images.
The advantage is that a filesystem can be made portable between operating systems as the high-level operating system functions it uses can be as common as ANSI C, but the disadvantage is that the API is unique to each application that implements one.
Examples of this scheme are the hfsutils and the adflib.
[edit] Interoperatibility between filesystem APIs
As all filesystems (at least the disk ones) need equivalent functions provided by the kernel, it is possible to easily port a filesystem code from one API to another, even if they are of different types.
For example, the ext2 driver for OS/2 is simply a wrapper from the Linux's VFS to the OS/2's IFS and the Linux's ext2 kernel-based, and the HFS driver for OS/2 is a port of the hfsutils to the OS/2's IFS. There also exists a project that uses a Windows NT IFS driver for making NTFS work under Linux.
[edit] Bibliography
- O'Reilly - Windows NT File System Internals, A Developer's Guide - By Rajeev Nagar - ISBN 1-56592-249-2
- Microsoft Press - Inside Windows NT File System - By Helen Custer - ISBN 1-55615-660-X
- Wiley - UNIX Filesystems: Evolution, Design, and Implementation - By Steve D. Pate - ISBN 0-471-16483-6
- Microsoft Press - Inside Windows NT - By Helen Custer - ISBN 1-55615-481-X
[edit] See also
- File system
- Installable File System
- Filing OSID
- List of file systems
- Comparison of file systems
- Filename extension
- Virtual file system
