Dateien-11

Files-11 ist das Dateisystem, das in den Betriebssystemen RSX-11 , IAS und OpenVMS von Digital Equipment Corporation verwendet wird . Es unterstützt datensatzorientierte Ein-/Ausgabe , Netzwerkzugriff und Dateiversionierung . Die ursprüngliche ODS-1-Schicht ist ein flaches Dateisystem ; die ODS-2-Version ist ein hierarchisches Dateisystem mit Unterstützung für Zugriffskontrolllisten .

Files-11 ist ähnlich wie die Dateisysteme, die in früheren Betriebssystemen der Digital Equipment Corporation wie TOPS-20 und RSTS/E verwendet wurden, jedoch wesentlich fortschrittlicher .

Die ursprüngliche ODS-1-Version von Files-11 bot eine einfache, nicht-hierarchische Verzeichnisstruktur, bei der jedem Benutzerkonto ein eigenes Verzeichnis zugewiesen wurde. Jedes Benutzerkonto wurde durch zwei Zahlen (ein Zahlenpaar) repräsentiert und hatte ein zugehöriges Verzeichnis; dies ähnelte dem RSTS/E-Dateisystem. Spezielle Systemdateien, wie z. B. ausführbare Programmdateien und das Betriebssystem selbst, wurden im Verzeichnis eines reservierten Systemkontos gespeichert. [project,programmer]

Während dies für PDP-11- Systeme mit ihrer begrenzten permanenten Speicherkapazität geeignet war, benötigten VAX- Systeme mit ihren viel größeren Festplatten eine flexiblere Methode der Dateispeicherung. Daher bot die in VMS eingeführte ODS-2-Version von Files-11 insbesondere ein hierarchisches Verzeichnislayout.

„Files-11“ ist die allgemeine Bezeichnung für fünf separate Dateisysteme, die als On-Disk Structure (ODS) Level 1 bis 5 bekannt sind.

ODS-1 ist das flache Dateisystem , das vom RSX-11-Betriebssystem verwendet wird und von älteren VMS- Systemen aus Gründen der RSX-Kompatibilität unterstützt wird, aber nie zur Unterstützung von VMS selbst verwendet wurde; es wurde weitgehend durch ODS-2 und ODS-5 ersetzt.

ODS-2 ist das ursprüngliche VMS-Dateisystem. Im Vergleich zu ODS-1 ist es ein hierarchisches Dateisystem .

Obwohl sie selten mit ihren ODS-Level-Bezeichnungen bezeichnet werden, handelt es sich bei ODS-3 und ODS-4 um die Files-11-Unterstützung für die Dateisysteme CD-ROM ISO 9660 bzw. High Sierra Format .

ODS-5 ist eine erweiterte Version von ODS-2, die auf Alpha- , IA-64- und x86-64 -Plattformen verfügbar ist. Sie bietet Unterstützung für Dateinamen mit Groß-/Kleinschreibung und Nicht- ASCII- Zeichen sowie Verbesserungen der hierarchischen Verzeichnisstruktur. Ursprünglich war sie für die Dateibereitstellung an Microsoft Windows und andere Nicht-VMS-Systeme im Rahmen des „NT Affinity“-Projekts vorgesehen, wird aber auch auf Benutzerdatenträgern und Internetservern eingesetzt .

Alle Dateien und Verzeichnisse eines Files-11-Dateisystems befinden sich in einem oder mehreren übergeordneten Verzeichnissen und schließlich im Stammverzeichnis, dem Master-Dateiverzeichnis (siehe unten). Das Dateisystem ist daher in einer gerichteten azyklischen Graphstruktur ( DAG ) organisiert.

In diesem Beispiel ( siehe rechts ) File 2hat die Datei einen Verzeichniseintrag sowohl unter Dir 2als auch unter Dir 3; sie ist in beiden Verzeichnissen gleichzeitig vorhanden. Selbst wenn sie aus einem Verzeichnis gelöscht wird, bleibt sie im anderen Verzeichnis erhalten, bis sie auch dort gelöscht wird. Dies ähnelt dem Konzept von Hardlinks in UNIX , wobei jedoch darauf geachtet werden muss, dass die Datei nicht auf Datenträgern gelöscht wird, die nicht für Hardlinks konfiguriert sind (dies ist nur auf ODS-5-Datenträgern verfügbar und auch dort nur, wenn Hardlinks aktiviert sind).

Ein betriebsbereites VMS-System hat Zugriff auf eine oder mehrere Online-Festplatten, von denen jede ein vollständiges, unabhängiges Dateisystem enthält. Dies sind entweder lokaler Speicher oder, im Falle eines Clusters, gemeinsam mit entfernten Systemen genutzter Speicher.

In einer OpenVMS-Clusterkonfiguration werden nicht-private Festplatten von allen Knoten im Cluster gemeinsam genutzt (siehe Abbildung 1) . In dieser Konfiguration sind die beiden Systemfestplatten für beide Knoten über das Netzwerk zugänglich, die private Festplatte hingegen wird nicht gemeinsam genutzt: Sie ist ausschließlich für die Verwendung durch einen bestimmten Benutzer oder Prozess auf diesem Rechner eingebunden. Der Dateizugriff im gesamten Cluster wird vom OpenVMS Distributed Lock Manager verwaltet, einem integralen Bestandteil des Dateisystems.

Mehrere Festplatten können zu einer einzigen großen logischen Festplatte oder einem Volume-Set zusammengefasst werden. Festplatten können auch automatisch in Schatten-Sets repliziert werden, um die Datensicherheit zu erhöhen oder eine schnellere Lesegeschwindigkeit zu erzielen.

Eine Festplatte wird entweder durch ihren physischen Namen oder (häufiger) durch einen benutzerdefinierten logischen Namen identifiziert. Beispielsweise kann das Boot-Gerät (Systemfestplatte) den physischen Namen haben , wird aber im Allgemeinen durch den logischen Namen$3$DKA100 referenziert . SYS$SYSDEVICE

Die Dateisysteme auf den einzelnen Festplatten (mit Ausnahme von ODS-1) sind hierarchisch aufgebaut. Ein vollständiger Dateiname besteht aus einem Knotennamen, einem Benutzernamen und einem Passwort, einem Gerätenamen, einem Verzeichnis, einem Dateinamen, einem Dateityp und einer Versionsnummer im folgenden Format:

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

Beispielsweise [DIR1.DIR2.DIR3]FILE.EXTbezieht sich auf die neueste Version von FILE.EXT, auf der aktuellen Standardfestplatte im Verzeichnis [DIR1.DIR2.DIR3].

DIR1ist ein Unterverzeichnis des Master File Directory (MFD) oder Stammverzeichnisses und DIR2ist ein Unterverzeichnis von DIR1. Das MFD einer Festplatte wird durch identifiziert [000000].

Die meisten Teile des Dateinamens können weggelassen werden; in diesem Fall werden sie aus der aktuellen Standarddateispezifikation übernommen . Die Standarddateispezifikation ersetzt das Konzept des „aktuellen Verzeichnisses“ anderer Betriebssysteme, indem sie Standardwerte für Knoten, Gerätenamen und Verzeichnis vorgibt. Alle Prozesse verfügen über eine Standarddateispezifikation, die Datenträgernamen und Verzeichnis enthält. Die meisten VMS-Dateisystemroutinen akzeptieren eine Standarddateispezifikation, die auch den Dateityp enthalten kann. Der TYPEBefehl verwendet beispielsweise standardmäßig .LISden Dateityp "", sodass der Befehl TYPE Fohne Dateiendung versucht, die Datei zu öffnen F.LIS.

Jede Datei besitzt eine Versionsnummer, die standardmäßig 1 ist, falls keine anderen Versionen mit demselben Dateinamen existieren (ansonsten 1 höher als die höchste Versionsnummer). Beim Speichern einer Datei wird nicht die bestehende Version überschrieben, sondern eine neue Datei mit demselben Namen, aber einer inkrementierten Versionsnummer erstellt. Alte Versionen können explizit mit dem DELETEBefehl `delete` PURGEoder `delete` gelöscht werden. Alternativ können ältere Versionen einer Datei auch automatisch gelöscht werden, sobald das Versionslimit der Datei erreicht ist (festgelegt durch `delete` SET FILE/VERSION_LIMIT). Alte Versionen werden somit nicht überschrieben, sondern bleiben auf der Festplatte erhalten und können jederzeit wiederhergestellt werden. Die maximale Anzahl an Versionsnummern beträgt 32767. Das Versionsverhalten lässt sich bei Bedarf einfach anpassen. Insbesondere Dateien, die direkt aktualisiert werden, wie z. B. Datenbanken, erstellen keine neuen Versionen, sofern dies nicht explizit programmiert ist.

ODS-2 ist auf acht Unterverzeichnisebenen beschränkt und erlaubt nur alphanumerische Namen in Großbuchstaben (plus Unterstrich, Bindestrich und Dollarzeichen) mit bis zu 39,39 Zeichen (39 für den Dateinamen und weitere 39 für die Dateiendung). ODS-5 erweitert den Zeichensatz um Kleinbuchstaben und die meisten anderen druckbaren ASCII-Zeichen sowie ISO- Latin-1- und Unicode- Zeichen, erhöht die maximale Dateinamenlänge und ermöglicht unbegrenzt viele Unterverzeichnisebenen. Beim Erstellen eines Pfadnamens für eine ODS-5-Datei, der Zeichen enthält, die unter ODS-2 nicht zulässig sind, wird eine spezielle Syntax mit dem Zeichen „^“ verwendet, um die Abwärtskompatibilität zu gewährleisten. Die Datei „ file.tar.gz;1“ auf einer ODS-5-Disk würde beispielsweise als „“ bezeichnet file^.tar.gz– der Dateiname ist „ file.tar“ und die Dateiendung ist „ .gz“.

Die Zugriffskontrolle basiert auf Benutzeridentifikationscodes (UICs). Ein UIC besteht aus einer Benutzernummer und einer Gruppennummer; letztere wird auch als Projektnummer bezeichnet. Jeder angemeldete Benutzer besitzt einen UIC, und jede Datei ist einem UIC zugeordnet.

In RSX-11 und IAS wird die Zugriffskontrolle durch vier Berechtigungsgruppen geregelt: ^{[ 1 ] [ 2 ] [ 3 ] [ 4 ]}

• System
• Eigentümer
• Gruppe
• Welt

Und vier Berechtigungsbits:

• Lesen
• Schreiben
• Verlängern
• Löschen

Der Zugriff „System“ gilt für jeden Benutzer, dessen UIC-Gruppennummer kleiner oder gleich 10 (oktal ) bzw. 8 (dezimal) ist; „Besitzer“ und „Gruppe“ gelten für den Besitzer der Datei und die Benutzergruppe dieses Benutzers, und „Welt“ gilt für jeden anderen Benutzer.

In VMS sind die vier Berechtigungsbits:

• Lesen
• Schreiben
• Ausführen
• Löschen

mit der Berechtigung „Ausführen“ anstatt der Berechtigung „Erweitern“.

Der Systemzugriff gilt für alle Benutzer, deren UIC-Gruppennummer kleiner oder gleich dem Systemparameter MAXSYSGROUP(typischerweise 8 oder 10 oktal ) ist. Zusätzlich gibt es ein fünftes Berechtigungsbit, „Control“, das den Zugriff auf Änderungen von Dateimetadaten wie dem Schutz bestimmt. Diese Gruppe kann nicht explizit festgelegt werden; sie ist immer für System und Besitzer gesetzt, jedoch nie für Gruppe oder Welt.

Die Dateisicherheit wird außerdem durch vier Systemberechtigungen beeinflusst , die es Benutzern, die diese besitzen, ermöglichen, Zugriffskontrollen außer Kraft zu setzen:

• BYPASSDer Benutzer hat implizit Lese-, Schreib- und Ausführungszugriff auf alle Dateien, unabhängig vom Dateischutz;
• READALLDer Benutzer hat implizit R-Zugriff auf alle Dateien;
• SYSPRVDer Benutzer kann auf Dateien zugreifen, die durch den Systemschutz geschützt sind;
• GRPPRVEin Benutzer kann auf Dateien zugreifen, die durch den Systemschutz geschützt sind, wenn seine UIC-Gruppe mit der Gruppe der Datei übereinstimmt.

VMS 4.0 führte die ACL -basierte Zugriffskontrolle ein. ACLs ermöglichen die Zuweisung zusätzlicher Berechtigungen benutzer- oder gruppenspezifisch; beispielsweise kann der Benutzer-ID (UIC) eines Webservers Lesezugriff auf alle Dateien in einem bestimmten Verzeichnis erhalten. ACLs können als vererbbar markiert werden , sodass die ACL einer Verzeichnisdatei für alle darin enthaltenen Dateien gilt. ACLs werden mit dem EDIT/ACLBefehl `git add` geändert und bestehen aus Kennungs-/Zugriffsadressenpaaren. Beispiel: Der ACL-Eintrag `git add`

(IDENTIFIER=HTTP$SERVER,ACCESS=READ+EXECUTE) 

würde dem Benutzer ermöglichen, HTTP$SERVERdie Datei zu lesen und auszuführen.

Ein logischer Name ist eine Systemvariable, die auf eine Festplatte, ein Verzeichnis oder eine Datei verweisen oder andere programmspezifische Informationen enthalten kann. Beispielsweise SYS$SYSDEVICEenthält der logische Name das Boot-Gerät des Systems. Normalerweise bezieht sich ein logischer Name auf ein einzelnes Verzeichnis oder eine Festplatte, z.SYS$LOGIN: B. das Benutzerverzeichnis (oder die Benutzerverzeichnisse). Diese logischen Namen können nicht als echte Festplattennamen verwendet werden – SYS$LOGIN:[DIR]FILEdies ist keine gültige Dateispezifikation. Versteckte logische Namen, die durch definiert werden DEFINE/TRANSLATION=CONCEALED, können jedoch auf diese Weise verwendet werden. Diese Verzeichnisse mit Stammverzeichnis werden durch einen nachgestellten Punkt („.“) in der Verzeichnisspezifikation definiert.

$ DEFINE/TRANS=CONCEAL HOME DISK$USERS:[ username .] 

Dies würde die Verwendung ermöglichen HOME:[DIR]FILE. Häufiger sind jedoch einfache logische Pfade, die auf bestimmte Verzeichnisse verweisen, die zu einer Anwendungssoftware gehören und sich auf einer beliebigen Festplatte oder in einem beliebigen Verzeichnis befinden können. So kann beispielsweise der logische Pfad ABC_EXE auf ein Verzeichnis mit ausführbaren Programmen der Anwendung ABC verweisen, und ABC_TEMP kann auf ein Verzeichnis mit temporären Dateien derselben Anwendung verweisen. Dieses Verzeichnis kann sich auf derselben Festplatte und im selben Verzeichnisbaum wie ABC_EXE befinden oder auf einer anderen Festplatte (und in einem anderen Verzeichnisbaum).

In ähnlicher Weise wie bei Unix definiert VMS mehrere Standard-Ein- und Ausgabekanäle , auf die über die logischen Namen SYS$INPUT, SYS$OUTPUT, SYS$ERRORund zugegriffen wird SYS$COMMAND. ^{[ 5 ]}

Logische Namen haben in POSIX-Betriebssystemen kein direktes Äquivalent. Sie ähneln Unix- Umgebungsvariablen , werden jedoch vom Dateisystem anstatt von der Befehlsshell oder einem Anwendungsprogramm expandiert. Da sie vor ihrer Verwendung definiert werden müssen, ist es üblich, viele logische Namen in der Systemstartdatei sowie in den Anmeldedateien der Benutzer zu definieren. In VMS können logische Namen auf andere logische Namen verweisen (bis zu einer vordefinierten Verschachtelungsgrenze von 10) und Namenslisten enthalten, um nach einem vorhandenen Dateinamen zu suchen. Einige häufig verwendete logische Namen sind:

AmigaOS ist das Betriebssystem, das dem Konzept logischer Namen am nächsten kommt und über den ASSIGNBefehl `amiga` unterstützt. Das Festplattenbetriebssystem von AmigaOS, AmigaDOS , eine Portierung von TRIPOS , weist einige Ähnlichkeiten zu DEC-Betriebssystemen auf. Beispielsweise folgen die Namen physischer Geräte einem Muster wie DF0: für die erste Diskette, CDROM2: für das dritte CD-ROM-Laufwerk usw. Da das System jedoch von jedem angeschlossenen Laufwerk booten kann, erstellt das Betriebssystem die Zuweisung `SYS:`, um automatisch auf das verwendete Boot-Gerät zu verweisen. Weitere Zuweisungen wie `LIBS:`, `PREFS:`, `C:`, `S:` usw. werden ebenfalls erstellt und beziehen sich ihrerseits auf `SYS:`. Benutzer können selbstverständlich auch eigene Zuweisungen erstellen und löschen.

Die Record Management Services (RMS) bilden die strukturierte Ein-/Ausgabeschicht des VMS-Betriebssystems. RMS bietet umfassende Programmunterstützung für die Verwaltung strukturierter Dateien , wie z. B. datensatzbasierte und indizierte Datenbankdateien . Das VMS-Dateisystem erweitert in Verbindung mit RMS den Dateizugriff über einfache Byte -Streams hinaus und ermöglicht die Unterstützung einer Vielzahl komplexer Dateitypen auf Betriebssystemebene. Jede Datei im VMS-Dateisystem kann als Datenbank betrachtet werden , die eine Reihe von Datensätzen enthält , von denen jeder ein oder mehrere Felder besitzt . Eine Textdatei ist beispielsweise eine Liste von Datensätzen (Zeilen), die durch Zeilenumbrüche getrennt sind. RMS ist ein Beispiel für ein datensatzorientiertes Dateisystem .

RMS definiert vier Datensatzformate :

• Feste Länge – alle Datensätze in der Datei haben die gleiche Länge.
• Variable Länge – die Datensätze variieren in ihrer Länge, und jedem Datensatz ist ein Zählbyte vorangestellt, das seine Länge angibt.
• Variable Datensatzlänge mit Steuerblock fester Länge – die Datensätze variieren in ihrer Länge, werden aber jeweils von einem Steuerblock fester Länge eingeleitet.
• Ein Datenstrom besteht aus Datensätzen unterschiedlicher Länge, die jeweils durch ein Trennzeichen voneinander getrennt sind. Eine Textdatei ist ein Beispiel für eine Datei im Datenstromformat, bei der Zeilenumbrüche oder Wagenrückläufe zur Trennung der Datensätze verwendet werden.

Es gibt vier Methoden zum Zugriff auf Datensätze bzw. Methoden zum Abrufen vorhandener Datensätze aus Dateien:

• Sequenzieller Zugriff – beginnend mit einem bestimmten Datensatz werden die nachfolgenden Datensätze der Reihe nach abgerufen, bis zum Ende der Datei.
• Zugriff über relative Datensatznummern – Datensätze werden über eine Datensatznummer relativ zum Dateianfang abgerufen.
• Zugriff auf Datensatzdateiadressen - Datensätze werden direkt über ihren Speicherort in der Datei (RFA oder Datensatzdateiadresse) abgerufen.
• Indexierter Zugriff – Datensätze werden über einen Schlüssel in Form einer Schlüssel-Wert-Zuordnung abgerufen .

Auf Festplattenebene stellt ODS das Dateisystem als Array von Blöcken dar , wobei ein Block 512 zusammenhängende Bytes auf einer physischen Festplatte ( Volume ) umfasst. Festplattenblöcke werden in Clustern angeordnet (ursprünglich 3 zusammenhängende Blöcke, später mit größeren Festplatten erhöht). Idealerweise ist eine Datei auf der Festplatte vollständig zusammenhängend, d. h. die Blöcke, die die Datei enthalten, sind sequenziell. Aufgrund von Festplattenfragmentierung muss die Datei jedoch manchmal in nicht zusammenhängenden Clustern gespeichert werden; in diesem Fall werden die Fragmente als Extents bezeichnet. Festplatten können zu einem Volume-Set zusammengefasst werden , und Dateien können auf beliebigen Festplatten dieses Sets gespeichert werden. Größere Festplatten haben die Verwendung von Volume-Sets jedoch reduziert, da die Verwaltung einer einzelnen physischen Festplatte einfacher ist.

Jede Datei auf einer Files-11-Disk (oder einem Volume-Set) besitzt eine eindeutige Dateikennung (FID), die sich aus drei Zahlen zusammensetzt: der Dateinummer (NUM), der Dateisequenznummer (SEQ) und der relativen Volume-Nummer (RVN). Die NUM gibt an, wo INDEXF.SYSsich die Metadaten der Datei innerhalb der Datei befinden (siehe unten). Die SEQ ist eine Generationsnummer, die beim Löschen der Datei und der anschließenden Erstellung einer neuen Datei unter Verwendung desselben INDEXF.SYS-Eintrags inkrementiert wird (um zu verhindern, dass verwaiste Verweise auf die alte Datei versehentlich auf die neue verweisen). Die RVN gibt die Volume-Nummer an, auf der die Datei bei Verwendung eines Volume-Sets gespeichert ist.

Die strukturelle Unterstützung eines ODS-Volumes wird durch eine Verzeichnisdatei bereitgestellt – eine spezielle Datei, die eine Liste von Dateinamen, Dateiversionsnummern und den zugehörigen FIDs enthält, ähnlich den VSAM-Katalogen auf MVS und Verzeichnissen auf Unix -Dateisystemen und NTFS . Im Stammverzeichnis der Verzeichnisstruktur befindet sich das Master File Directory (MFD), das Wurzelverzeichnis, das (direkt oder indirekt) jede Datei auf dem Volume enthält.

Im obersten Verzeichnis eines ODS-Dateisystems befindet sich das Master File Directory (MFD). Es enthält alle Verzeichnisdateien der obersten Ebene (einschließlich des MFD selbst) sowie mehrere Systemdateien zur Speicherung von Dateisysteminformationen. Bei ODS-1-Volumes wird eine zweistufige Verzeichnisstruktur verwendet: Jedem Benutzeridentifikationscode (UIC) ist ein Benutzerdateiverzeichnis (UFD) der Form `/ userfiledirectory[GROUP.USER] / ...

Folgende Systemdateien sind im ODS MFD vorhanden:

• INDEXF.SYS;1—Indexdatei
• BITMAP.SYS;1—Speicher-Bitmap-Datei
• BADBLK.SYS;1—Fehlerhafte Blockdatei
• 000000.DIR;1—Die MFD-Verzeichnisdatei selbst
• CORIMG.SYS;1—Core-Image-Datei
• VOLSET.SYS;1—Volume-Set-Listendatei (nur ODS-2/5)
• CONTIN.SYS;1—Fortsetzungsdatei (nur ODS-2/5)
• BACKUP.SYS;1—Sicherungsprotokolldatei (nur ODS-2/5)
• BADLOG.SYS;1—Ausstehender fehlerhafter Block (nur ODS-2/5)
• SECURITY.SYS;1—Volume-Sicherheitsprofil (nur ODS-2/5)
• QUOTA.SYS;1—Kontingentdatei (optional und nur unter ODS-2/5 verfügbar)
• GPT.SYS;1—GUID-Partitionierungstabelle (GPT) (OpenVMS I64 EFI-Bootstrukturen, optional unter OpenVMS Alpha)

Beachten Sie, dass die Dateisystemimplementierung selbst diese Dateien nicht über ihren Namen, sondern über ihre Datei-IDs referenziert, die immer die gleichen Werte haben. Daher ist INDEXF.SYS immer die Datei mit den Werten NUM = 1und SEQ = 1.

Die Indexdatei enthält die grundlegendsten Informationen über einen Files-11-Volume-Satz.

Es gibt zwei Organisationsformen von INDEXF.SYS: die traditionelle Organisation und die Organisation, die auf Datenträgern mit GPT.SYS verwendet wird; mit den GUID Partition Table (GPT)-Strukturen.

Bei der traditionellen Organisation ist Block 1 der Bootblock . Er enthält die Adresse des primären Bootstrap-Images , das zum Laden des VMS-Betriebssystems verwendet wird. Dieser befindet sich immer an logischer Stelle 0 auf der Festplatte, damit die Hardware-Firmware ihn lesen kann. Dieser Block ist immer vorhanden, auch auf Nicht-Systemvolumes (nicht bootfähigen Volumes).

After the boot block is the primary home block. This contains the volume name, the location of the extents comprising the remainder of the index file, the volume owner's UIC, and the volume protection information. There are normally several additional copies of the home block, known as the secondary home blocks, to allow recovery of the volume if it is lost or damaged.

On disks with GPT.SYS, GPT.SYS contains the equivalent of the boot block (known as the Master Boot Record (MBR)), and there is no primary home block. All home blocks present on a GPT-based disk are alternate home blocks. These structures are not included in INDEXF.SYS, and the blocks of the INDEXF.SYS file are unused.

The rest of the index file is composed of file headers, which describe the extents allocated to the files residing on the volume, and file metadata such as the owner UIC, ACLs and protection information. Each file is described by one or more file headers—more than one can be required when a file has a large number of extents. The file header is a fixed-length block, but contains both fixed– and variable–length sections:

• The header contains the NUM and SEQ, the protection (security) information, and the location of the rest of the file header.
• The ident section contains the accounting metadata: the filename, creation and modification times, and the time of the last backup.
• The map describes which physical disk blocks (extents) map to each virtual block of the file.
• The access control list contains the ACL information for the file.
• The reserved area is space at the end of the file header which is not used by the operating system. This can be used by for customer- or vendor-specific information.
• The last two bytes of the header are a checksum of the previous 255 words, to verify the validity of the header.

If possible, the map and ACL sections of the header are contained completely in the primary header. However, if the ACL is too long, or the file contains too many extents, there will not be enough space in the primary header to store them. In this case, an extension header is allocated to store the overflow information.

Der Dateikopf beginnt mit vier Offsets ( IDOFFSET , MPOFFSET , ACOFFSET und ROFFSET ). Da die Größe der Bereiche nach dem Header fester Länge variieren kann (z. B. der Karten- und ACL-Bereich), werden die Offsets benötigt, um diese zusätzlichen Bereiche zu lokalisieren. Jeder Offset entspricht der Anzahl der 16-Bit-Wörter vom Beginn des Dateikopfes bis zum Beginn des jeweiligen Bereichs.

Falls die Datei mehrere Header benötigt, enthält die Erweiterungssegmentnummer ( SEGNUM ) die Sequenznummer dieses Headers, beginnend bei 0 im ersten Eintrag in INDEXF.SYS.

STRUCLEV enthält die aktuelle Strukturebene (im höherwertigen Byte) und die Version (im niederwertigen Byte) des Dateisystems; ODS-2 entspricht Strukturebene 2. Eine Erhöhung der Versionsnummer deutet auf eine abwärtskompatible Änderung hin, die von älterer Software möglicherweise ignoriert wird; Änderungen auf der Strukturebene selbst sind inkompatibel.

W_FID (bestehend aus den drei Werten FID_NUM , FID_SEQ und FID_RVN , entsprechend Datei, Sequenz und relativer Datenträgernummer) enthält die ID dieser Datei; EXT_FID (ebenfalls bestehend aus drei Werten) enthält die Position des nächsten Erweiterungsheaders, falls vorhanden. In beiden Werten ist die RVN auf 0 gesetzt, um den „aktuellen“ Datenträger darzustellen (0 ist normalerweise keine gültige RVN).

FILECHAR enthält mehrere Flags, die Einfluss darauf haben, wie die Datei verarbeitet oder organisiert wird:

• Die Einstellung NOBACKUP bewirkt, dass diese Datei bei der Durchführung einer Datensicherung ignoriert wird .
• WRITEBACK ermöglicht zwischengespeicherte (verzögerte) Schreibvorgänge in die Datei.
• READCHECK bewirkt, dass alle Lesevorgänge der Datei zweimal durchgeführt und verglichen werden, um die Datenintegrität sicherzustellen.
• WRITCHECK führt dazu, dass alle Schreibvorgänge durch einen nachfolgenden Lese- und Vergleichsvorgang verifiziert werden.
• CONTIGB veranlasst das Betriebssystem, den Speicherplatz für die Datei so zusammenhängend wie möglich zuzuweisen.
• Der Wert LOCKED wird gesetzt, wenn die Datei gesperrt ist. Ist dieser Wert gesetzt, bedeutet dies, dass die Datei nach ihrer letzten Verwendung nicht ordnungsgemäß geschlossen wurde und ihr Inhalt möglicherweise inkonsistent ist.
• CONTIG bedeutet, dass die Datei zusammenhängend auf der Festplatte gespeichert ist; das heißt, jeder virtuelle Block i wird dem logischen (physischen) Block i + k zugeordnet, wobei k eine Konstante ist .
• BADACL wird gesetzt, wenn die Datei eine ungültige Zugriffssteuerungsliste hat.
• SPOOL wird gesetzt, wenn es sich bei der Datei um eine Spool-Datei handelt, z. B. um eine temporäre Datei, die während des Druckvorgangs verwendet wird.
• DIRECTORY wird gesetzt, wenn es sich bei der Datei um ein Verzeichnis handelt.
• BADBLOCK wird gesetzt, wenn die Datei fehlerhafte Blöcke enthält.
• MARKDEL wird gesetzt, wenn die Datei zum Löschen markiert wurde, aber noch verwendet wird; sie wird gelöscht, sobald sie vom letzten Benutzer geschlossen wird.
• Wenn die Option NOCHARGE gesetzt ist, wird der vom Dateisystem belegte Speicherplatz nicht vom Speicherkontingent des Besitzers abgezogen.
• ERASE bewirkt, dass der Inhalt der Datei beim Löschen überschrieben wird.

ACCMODE beschreibt die Berechtigungsstufe , die ein Prozess für den Zugriff auf die Datei benötigt. VMS definiert vier Berechtigungsstufen: Benutzer, Supervisor, Ausführung und Kernel. Jeder Zugriffstyp – Lesen, Schreiben, Ausführen und Löschen – wird als 2-Bit-Ganzzahl kodiert.

FILEPROT enthält die Informationen zur Zugriffskontrolle für die Datei. Sie ist in vier Gruppen mit je vier Bits unterteilt: System, Besitzer, Gruppe und Welt. Bit 0 steht für Lesezugriff, Bit 1 für Schreibzugriff, Bit 2 für Ausführungszugriff und Bit 3 für Löschzugriff. Durch Setzen eines Bits wird der Zugriff einer bestimmten Gruppe verweigert; durch Löschen wird er gewährt.

Handelt es sich bei dem Dateikopf um einen Erweiterungskopf, enthält BACKLINK die Datei-ID des primären Kopfes; andernfalls enthält er die Datei-ID der Verzeichnisdatei, die den primären Eintrag für die Datei enthält.

• Speicherbitmap-Datei:BITMAP.SYS

Die Bitmap-Datei speichert Informationen über den belegten und verfügbaren Speicherplatz eines Datenträgers. Sie enthält den Speicherkontrollblock (SCB) mit zusammenfassenden Informationen zu den Speicherbelegungen sowie die Bitmap, ein Bit-Array, das angibt, ob ein Blockcluster auf der Festplatte frei oder belegt ist. In früheren Versionen von VMS umfasste der Cluster drei Blöcke; mit zunehmender Festplattengröße hat sich auch die Clustergröße erhöht.

• Fehlerhafte Blockdatei:BADBLK.SYS

Die Datei mit den fehlerhaften Blöcken enthält alle bekannten fehlerhaften Blöcke des physischen Datenträgers. Sie dient dazu, zu verhindern, dass das System diese Blöcke Dateien zuweist. Diese Datei wurde vor allem in der Frühzeit der Festplattenherstellung verwendet, als Festplatten üblicherweise mit mehr fehlerhaften Bereichen an der Oberfläche hergestellt wurden.

• Datei mit der Liste der Datenträger:VOLSET.SYS

Die Liste der Bände eines Bandsatzes befindet sich auf Band 1 und enthält eine Liste der Bezeichnungen aller Bände des Satzes sowie den Bandnamen des Satzes.

• Fortsetzungsdatei:CONTIN.SYS

Wenn eine Datei auf einem mehrteiligen Datenträger die Grenze zweier Teildatenträger überschreitet, wird die Fortsetzungsdatei als Erweiterungskopf verwendet und beschreibt den Datenträger, auf dem der Rest der Datei zu finden ist.

• Quotendatei:QUOTA.SYS

Die Quota-Datei enthält Informationen zur Speicherplatznutzung jeder UIC auf einem Volume. Sie enthält einen Eintrag für jede UIC mit zugewiesenem Speicherplatz auf einem Volume sowie Informationen darüber, wie viel Speicherplatz diese UIC belegt. HINWEIS: Die Funktion „DISK QUOTA“ ist optional, und die Datei existiert nur, wenn die Funktion jemals aktiviert wurde.

• Volume-Sicherheitsprofil:SECURITY.SYS

Das Volume-Sicherheitsprofil enthält die Besitzer-UIC des Volumes, die Volume-Schutzmaske und seine Zugriffssteuerungsliste.

• GUID-Partitionierungstabelle:GPT.SYS

Diese Datei überlagert und schützt die MBR- (Master Boot Record) und GPT-Datenträgerstrukturen (GUID Partitioning Table), die von der EFI- kompatiblen Firmware verwendet werden. Sie wird standardmäßig bei der Datenträgerinitialisierung von OpenVMS I64 und x86-64 erstellt und optional (mit INITIALIZE/GPT) unter OpenVMS Alpha.

• Vergleich der Dateisysteme

• Andrew C. Goldstein (1975-06-19). "Files-11 On-Disk Structure Specification" (PDF) .
• Andrew C. Goldstein (1985-01-11). "Files-11 On-Disk Structure Specification" .
• VMS Software, Inc. (August 2019). „Anhang A: Files-11-Disk-Struktur“. VSI OpenVMS System Manager's Manual, Band 2: Tuning, Monitoring und komplexe Systeme (PDF) .
• Kirby McCoy (1990). VMS File System Internals . Bedford, Mass.: Digital Press. ISBN 1-55558-056-4Die

• Leitfaden zu OpenVMS-Dateianwendungen
• VMS2Linux