File control block

A file control block is a per-file data structure maintained by the operating system to manage an open file instance. It typically contains the file's name, device identifier, current file position, access mode, and pointers to disk blocks or inodes. The FCB is created when a file is opened and updated as the file is read or written, ensuring that each process has a consistent view of the file's state.¹

In Unix-like systems, the FCB is conceptually split into the inode (which stores persistent metadata) and the file table entry (which holds dynamic state like the offset). In contrast, Windows NT uses a more unified structure called the File Object, which combines both aspects. The FCB is essential for enforcing access control and coordinating concurrent access, as it holds locks and permission flags.²

The term 'file control block' gained prominence with Digital Research's CP/M operating system, where it was a user-visible structure used for file operations via the BDOS interface. CP/M's FCB was a 36-byte structure containing fields for drive number, filename, extension, and extent information, and it was manipulated directly by application programs.

MS-DOS inherited this design, providing FCB-based file functions (INT 21h functions 0Fh–17h) for compatibility, though they were soon overshadowed by the more robust handle-based API. Early mainframe systems, such as IBM's OS/360, also used similar control blocks (e.g., the Data Control Block) to manage dataset I/O, reflecting the universal need for such structures.

In modern operating systems, the FCB has evolved into more abstract structures. Linux uses a combination of the inode, file structure, and dentry to represent an open file, with the file structure containing the current offset and flags. Windows NT uses the File Object, which is part of the object manager and includes a pointer to the file system's control block.³

Network file systems like NFS and SMB implement their own FCB-like structures to manage remote file state, often caching metadata locally to reduce network traffic. The concept also extends to database systems, where a similar structure, sometimes called a 'file descriptor' or 'file handle', is used to track open tables and indexes.⁴

One overlooked detail is that in CP/M, the FCB was not just an internal structure but a user-visible data area that programmers had to initialize manually, including setting the drive code and filename fields. This exposed the FCB to bugs, such as forgetting to clear the extent field, which could cause data corruption.

Another niche fact is that MS-DOS's FCB-based functions were notoriously limited: they could not handle subdirectories or long filenames, and they required the current directory to be set correctly. This led to their deprecation in favor of handle-based functions, but they remained for backward compatibility until Windows 9x.

In some early systems, the FCB was stored in memory adjacent to the file's data buffers, allowing direct manipulation by device drivers, which could lead to security vulnerabilities if not properly protected.⁵

Inode

A data structure in Unix-like file systems that stores metadata about a file, such as permissions, size, and disk block locations.

File descriptor

An integer handle used by a process to refer to an open file in Unix-like systems.

BDOS

Basic Disk Operating System, the core of CP/M that provided file management services.