File system API

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. Some file systems provide identification of records by key and may include re-writing an existing record. 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. As with writing run-time libraries may intercede for the user program.

Positioning includes adjusting the location of the next record. This may include skipping forward or reverse as well as positioning to the beginning or end of the file.

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. It updates system structures to indicate that the object is in use.

Usual requirements for requesting access to a file system object include:

1. The object which is to be accessed (file, directory, media and location)
2. The intended type of operations to be performed after the open (reads, updates, deletions)

Additional information may be necessary, for example

• a password
• a declaration that other processes may access the same object while the opening process is using the object (sharing). This may depend on the intent of the other process. In contrast, a declaration that no other process may access the object regardless of the other processes intent (exclusive use).

These are requested via a programming language library which may provide coordination among modules in the process in addition to forwarding the request to the file system.

It must be expected that something may go wrong during the processing of the open.

1. The object or intent may be improperly specified (the name may include an unacceptable character or the intent is unrecognized).
2. The process may be prohibited from accessing the object (it may be only accessible by a group or specific user).
3. The file system may be unable to create or update structures required to coordinate activities among users.
4. In the case of a new (or replacement) object, there may not be sufficient capacity on the media.

Depending on the programming language, additional specifications in the open may establish the modules to handle these conditions. Some libraries specify a library module to the file system permitting analysis should the opening program be unable to perform any meaningful action as a result of a failure. For example, if the failure is on the attempt to open the necessary input file, the only action may be to report the failure and abort the program. 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. The minimal specification to the close references the object. Additionally, some file systems provide specifying a disposition of the object which may indicate the object is to be discarded and no longer be part of the file system. Similar to the open, it must be expected that something may go wrong.

1. The specification of the object may be incorrect.
2. There may not be sufficient capacity on the media to save any data being buffered or to output a structure indicating that the object was successfully updated.
3. A device error may occur on the media where the object is stored while writing buffered data, the completion structure or updating meta data related to the object (for example last access time).
4. A specification to release the object may be inconsistent with other processes still using the object.

Considerations for handling a failure are similar to those of the open.

Information about the data in a file is called metadata.

Some of the metadata is maintained by the file system, for example last-modification date (and various other dates depending on the file system), location of the beginning of the file, the size of the file and if the file system backup utility has saved the current version of the files. These items cannot usually be altered by a user program.

Additional meta data supported by some file systems may include the owner of the file, the group to which the file belongs as well as permissions and/or access control (i.e. What access and updates various users or groups may perform), and whether the file is normally visible when the directory is listed. These items are usually modifiable by file system utilities which may be executed by the owner.

Some applications store more metadata. For images the metadata may include the camera model and settings used to take the photo. For audio files, the meta data may include the album, artist who recorded the recording and comments about the recording which may be specific to a particular copy of the file (i.e. different copies of the same recording may have different comments as update by the owner of the file). Documents may include items like checked-by, approved-by, etc.

Renaming a file, moving a file (or a subdirectory) from one directory to another and deleting a file are examples of the operations provide by the file system for the management of directories.

Metadata operations such as permitting or restricting access the a directory by various users or groups of users are usually included.

As a filesystem is used directories, files and records may be added, deleted or modified. This usually causes inefficiencies in the underlying data structures. Things like logically sequential blocks distributed across the media in a way that causes excessive repositioning, partially used even empty blocks included in linked structures. 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.

Specialized routines in the file system are included to optimize or repair these structures. They are not usually invoked by the user directly but triggered within the file system itself. Internal counters of the number of levels of structures, number of inserted objects may be compared against thresholds. These may cause user access to be suspended to a specific structure (usually to the displeasure of the user or users effected) or may be started as low priority asynchronous tasks or they may be deferred to a time of low user activity. Sometimes these routines are invoked or scheduled by the system manager or as in the case of defragmentation.