Files-11

Files-11
Company type	File system
Industry	Computer software
Predecessor	RSX-11 file system (ODS-1)
Founder	Dave Cutler (guidance)
Headquarters	United States
Products	File system for RSX-11 and OpenVMS operating systems
Owner	Digital Equipment Corporation

Files-11 serves as the file system for the RSX-11 and OpenVMS operating systems developed by Digital Equipment Corporation. It offers record-oriented I/O, enables remote network file access, and supports versioning of files. The initial ODS-1 implementation provided a flat file system, while ODS-2 introduced a hierarchical file system architecture featuring access control list capabilities.

Compared to earlier DEC operating systems such as TOPS-20 and RSTS/E, Files-11 represents a more sophisticated file management system.

History

The lineage of the OpenVMS file system traces back to previous DEC platforms, all engineered under the guidance of Dave Cutler. A principal distinction lies in directory organization: earlier designs employed a flat directory structure with one directory allocated per user account, which was adequate for the limited storage capacity of the PDP-11. With the advent of larger storage on VAX hardware, ODS-2 introduced hierarchical directories to provide enhanced organizational flexibility.

Overview

The term "Files-11" encompasses five distinct on-disk structure (ODS) formats:

ODS-1 represents a flat file system originally used by RSX-11. While still supported on legacy VMS systems for backward compatibility, it has largely been superseded by ODS-2 and ODS-5.

ODS-2 constitutes the foundational hierarchical file system implemented in VMS.

ODS-3 and ODS-4 correspond to support for CD-ROM standards ISO 9660 and High Sierra Format, respectively.

ODS-5 builds upon ODS-2 for use on Alpha, IA-64, and x86-64 architectures, introducing case-preserving filenames that include non-ASCII characters along with enhanced directory handling. Originally developed with "NT Affinity" in mind—to facilitate file sharing with Microsoft Windows and other non-VMS environments—ODS-5 is also widely deployed on user storage volumes and Internet-facing servers.

Directory layout

Files and directories exist as children within parent directories beneath the root-level master file directory, creating a directed acyclic graph (DAG) structure. For instance, File 2 can be linked within both Dir 2 and Dir 3, analogous to UNIX hard links. On ODS-5 volumes where hard links are enabled, deleting a file entry from one directory does not remove the actual data until all references across directories are eliminated.

Disk organization and naming

An active VMS environment manages one or more mounted disks, each containing an independent and complete file system instance. These disks may be physically local or, within cluster setups, shared remotely across multiple nodes.

In an OpenVMS cluster arrangement, non-private disks are accessible by all nodes (refer to figure 1). System disks are network-shared among all nodes, whereas private disks are mounted exclusively for individual users or specific processes. File access coordination within clusters is handled by the OpenVMS Distributed Lock Manager.

Multiple physical disks can be aggregated into a single logical entity called a volume set. Additionally, disks may be duplicated into shadow sets to enhance data redundancy or optimize read throughput.

Disks are identified using either physical device names or user-assigned logical names. For example, a boot device might have the physical designation $3$DKA100, yet it is commonly referred to via the logical name SYS$SYSDEVICE.

All file systems except ODS-1 employ hierarchical naming conventions. A complete filename incorporates nodename, account credentials, device identifier, directory path, filename, extension, and version number:

NODE"accountname password"::device:[directory.subdirectory]filename.type;ver

As an illustration, [DIR1.DIR2.DIR3]FILE.EXT points to the most recent version of FILE.EXT located within the specified directory on the default disk.

Directories are arranged in a hierarchy rooted at the master file directory (MFD), which is designated as [000000]. Most components of a filename can be omitted if defaults are set via a process's default file specification, replacing the concept of a "current directory" found in other operating systems.

Each file maintains a version number that increments with every save operation instead of overwriting existing data. Older versions may be deleted manually or automatically once version limits are reached. Versioning can be disabled for files such as databases that require direct updates.

Under ODS-2, directory nesting supports up to eight levels with uppercase alphanumeric names limited to 39 characters. ODS-5 expands this capability by allowing lowercase letters, extended ASCII, ISO Latin-1, and Unicode characters in filenames; it also removes limits on subdirectory depth and filename length. To maintain backward compatibility for filenames containing otherwise invalid characters under ODS-5, a special "^" notation is used.

File security: protection mechanisms and ACLs

VMS file security integrates access control based on User Identification Codes (UIC) with Access Control Lists (ACLs). The UIC-based permissions rely on file ownership and user classification into four distinct categories:

System
Owner
Group
World

The permission set includes Read, Write, Execute, Delete, along with a Control bit that governs metadata modifications (this bit is always enabled for System and Owner).

Certain system privileges can bypass standard access restrictions:

BYPASS: grants unrestricted RWED access regardless of protection settings
READALL: provides implicit read rights
SYSPRV: allows access according to System-level protections
GRPPRV: permits group-based access under system protection rules

ACLs allow detailed permission assignments for individual users or groups and support inheritance by subdirectories. These lists are configured through the EDIT/ACL utility.

Logical names

A logical name functions as a system variable that points to disks, directories, files, or application-specific data. For example, SYS$SYSDEVICE designates the device from which the system boots. Typically, logical names reference directories rather than acting as direct disk identifiers; however, hidden logical names enable references to rooted directories that behave similarly to disk names.

Logical names enable adaptable application deployment by directing to directories that may reside on various disks or locations. Common uses include defining executable file paths (ABC_EXE) or temporary storage locations (ABC_TEMP) for specific applications.

VMS standard input/output channels are accessed via logical names such as SYS$INPUT, SYS$OUTPUT, SYS$ERROR, and SYS$COMMAND. Unlike Unix environment variables, logical names are expanded by the file system rather than by shells or individual programs.

Typical logical names include:

Logical Name	Description
`SYS$INPUT`	Standard input source (keyboard terminal or batch input)
`SYS$OUTPUT`	Standard output destination (terminal display or batch log)
`SYS$ERROR`	Standard error output stream
`SYS$COMMAND`	Source for batch commands
`TT`	Terminal associated with the current process
`SYS$PRINT`	Default printer or print queue
`SYS$LOGIN`	User's home directory
`SYS$SCRATCH`	Directory for temporary files
`SYS$SYSTEM`	Directory containing system programs
`SYS$SHARE`	Shared runtime libraries and executables
`SYS$LIBRARY`	System and additional libraries

The concept most comparable outside DEC environments is AmigaOS's ASSIGN, which handles device assignments similar to logical names.

Record-oriented I/O: Record Management Services

Record Management Services (RMS) represents VMS's structured I/O framework designed for managing record-based files such as databases. RMS extends beyond simple byte stream file access by supporting records composed of multiple fields. In this context, text files are treated as sequences of records separated by newline characters.

RMS specifies four record formats:

Fixed length – records of constant size
Variable length – records preceded by a length byte
Variable length with fixed-length control block
Stream – records delimited by termination characters (e.g., lines of text)

To optimize data handling, RMS offers four record access methods:

Sequential Access – processing records in order from a starting point
Relative Record Number Access – direct retrieval using record numbers
Record File Address Access – direct access based on physical location
Indexed Access – key-based retrieval enabling associative array functionality

Physical Layout: On-Disk Organization

At the disk level, the On-Disk Structure (ODS) organizes the file system into 512-byte blocks grouped into clusters, which initially consist of three blocks. Ideally, files occupy consecutive blocks; however, when necessary, they can be divided into multiple extents. Volume sets enable several disks to function as a single logical volume, although their use has diminished due to larger disk capacities simplifying management tasks.

Each file is uniquely identified by a File Identification (FID), which consists of three components: the file number (NUM), sequence number (SEQ), and relative volume number (RVN). The NUM locates the file’s metadata within INDEXF.SYS. The SEQ increments whenever a file is deleted and recreated to avoid invalid references. The RVN specifies the particular volume within a volume set.

Directories

ODS volumes maintain directory files that catalog filenames, version numbers, and FIDs, functioning similarly to VSAM catalogs or directory structures in Unix and NTFS systems. The root directory contains the Master File Directory (MFD), which lists all top-level directories and critical system files.

The Master File Directory

The MFD serves as the repository for primary directories and vital system files that manage volume metadata. On ODS-1 volumes, directories are organized in a two-level hierarchy keyed by user identification codes (UIC). ODS-2 and later versions support flexible nested directories—up to eight levels deep in ODS-2 and unlimited depth in ODS-5. In multi-volume configurations, the MFD is located on the first volume and encompasses directories across all volumes.

Important system files housed within the MFD include:

INDEXF.SYS;1: Index metadata file
BITMAP.SYS;1: Storage allocation bitmap
BADBLK.SYS;1: Bad block tracking file
000000.DIR;1: MFD directory listing
CORIMG.SYS;1: Core image data
VOLSET.SYS;1: Volume set descriptor (ODS-2/5)
CONTIN.SYS;1: Continuation file for extended metadata (ODS-2/5)
BACKUP.SYS;1: Backup operation log (ODS-2/5)
BADLOG.SYS;1: Log of pending bad blocks (ODS-2/5)
SECURITY.SYS;1: Volume security profile (ODS-2/5)
QUOTA.SYS;1: Optional disk quota records
GPT.SYS;1: GUID Partition Table overlay used by OpenVMS I64 EFI boot

Internally, files are referenced by fixed identifiers rather than names. For instance, INDEXF.SYS consistently uses NUM=1 and SEQ=1.

Index File: INDEXF.SYS

The file INDEXF.SYS contains essential metadata for Files-11 volumes.

Conventionally, block 1 serves as the boot block that points to the primary bootstrap image located at logical block 0, facilitating firmware loading. This boot block exists even on volumes that are not bootable.

Following this is the primary home block, which stores details such as the volume name, locations of index extents, owner UIC, and protection attributes. Multiple secondary home blocks provide redundancy to support recovery processes.

On disks utilizing GPT with overlays like GPT.SYS replacing traditional boot structures, only secondary home blocks are present while INDEXF.SYS blocks remain unused.

The index consists of fixed-length file headers that describe extent allocations alongside metadata including owner UICs, access control lists (ACLs), and protection settings. Large files employ extension headers to accommodate overflow data such as extensive ACL entries or numerous extents.

File headers comprise several sections:

Header: Contains NUM/SEQ identifiers and protection information
Ident: Stores filename along with creation, modification, and backup timestamps
Map: Details physical disk extents mapping virtual blocks
Access Control List: Lists ACL entries governing permissions
Reserved Area: Space allocated for vendor-specific data
Checksum: Used to verify header integrity

Within headers, offsets point to variable-sized regions like maps and ACLs. Extension headers reference their associated primary headers via unique segment numbers that indicate their order in the sequence.

Flags embedded in headers define specific behaviors such as excluding files from backup (NOBACKUP), enabling write caching (WRITEBACK), performing integrity checks on reads/writes (READCHECK/WRITCHECK), providing hints about block contiguity (CONTIGB/CONTIG), or indicating states like locked (LOCKED) or spool files (SPOOL). Access modes specify required privilege levels for read, write, execute, or delete operations. File protection bits enforce discretionary access control across system, owner, group, and world classifications.

Other files

Storage bitmap file: BITMAP.SYS* — Manages allocation status by maintaining a storage control block alongside a bitmap array that reflects cluster usage; cluster sizes have expanded in line with increases in disk capacity.

Bad block file: BADBLK.SYS* — Contains a directory of defective disk blocks to avoid their assignment; this file was particularly important during earlier generations of disk hardware.

Volume set list file: VOLSET.SYS* — Found on the first volume within a set, it catalogs all volume labels and the overall set name.

Continuation file: CONTIN.SYS* — Facilitates multi-volume files by specifying the location of continuation data across volumes.

Quota file: QUOTA.SYS* — Maintains records of disk consumption per UIC when quota enforcement is activated.

Volume security profile: SECURITY.SYS* — Stores information about the volume owner’s UIC, protection mask, and access control list (ACL).

GUID Partitioning Table: GPT.SYS* — Safeguards EFI-compliant MBR/GPT structures on OpenVMS systems running on I64 architecture; its use is optional on Alpha-based platforms.

External links