Файлы-11

Files-11 — файловая система, используемая в операционных системах RSX-11 и OpenVMS от Digital Equipment Corporation . Она поддерживает ориентированный на записи ввод-вывод , удаленный сетевой доступ и управление версиями файлов . Исходный уровень ODS-1 — это плоская файловая система ; версия ODS-2 — это иерархическая файловая система с поддержкой списков контроля доступа .

Files-11 похожа на файловые системы, использовавшиеся в предыдущих операционных системах Digital Equipment Corporation, таких как TOPS-20 и RSTS/E , но значительно более продвинута .

Собственная файловая система OpenVMS произошла от более старых операционных систем DEC и во многом похожа, обе были разработаны Дэйвом Катлером . Основное различие заключается в расположении каталогов. Все эти файловые системы предоставляли некоторую форму рудиментарной неиерархической структуры каталогов, обычно основанной на назначении одного каталога на учетную запись пользователя. В RSTS/E каждая учетная запись пользователя была представлена ​​двумя числами, парой , и имела один связанный каталог. Специальные системные файлы, такие как исполняемые файлы программ и сама ОС, хранились в каталоге зарезервированной системной учетной записи.[project,programmer]

Хотя это подходило для систем PDP-11 , которые обладали ограниченной емкостью постоянного хранилища, системы VAX с гораздо большими жесткими дисками требовали более гибкого метода хранения файлов: в частности, иерархической структуры каталогов, что было наиболее заметным улучшением в ODS-2.

«Файлы-11» — это общее название пяти отдельных файловых систем, известных как структуры диска (ODS) уровней с 1 по 5.

ODS-1 — это плоская файловая система , используемая ОС RSX-11, поддерживаемая старыми системами VMS для совместимости с RSX, но никогда не использовавшаяся для поддержки самой VMS; она была в значительной степени вытеснена ODS-2 и ODS-5.

ODS-2 — это оригинальная файловая система VMS. По сравнению с ODS-1, это иерархическая файловая система .

Хотя ODS-3 и ODS-4 редко упоминаются по обозначениям уровня ODS, они представляют собой поддержку Files-11 для файловых систем CD-ROM ISO 9660 и High Sierra Format соответственно.

ODS-5 — это расширенная версия ODS-2, доступная на платформах Alpha , IA-64 и x86-64 , которая добавляет поддержку сохранения регистра имен файлов с не- ASCII символами и улучшения поддержки иерархических каталогов. Первоначально она была предназначена для обслуживания файлов в Microsoft Windows или других не-VMS системах в рамках проекта "NT Affinity", но также используется на пользовательских дисках и интернет- серверах.

Все файлы и каталоги в файловой системе Files-11 содержатся внутри одного или нескольких родительских каталогов и, в конечном итоге, под корневым каталогом, главным файловым каталогом (см. ниже). Таким образом, файловая система организована в виде структуры направленного ациклического графа ( DAG ).

В этом примере ( см. справа ) File 2есть запись каталога в обоих каталогах Dir 2и Dir 3; он находится «в» обоих каталогах одновременно. Даже если его удалить из одного, он все равно будет существовать в другом каталоге, пока не будет удален оттуда. Это похоже на концепцию жестких ссылок в UNIX , хотя необходимо следить за тем, чтобы файл фактически не был удален на дисках, которые не настроены для жестких ссылок (доступно только на дисках ODS-5, и то только если на диске включены жесткие ссылки).

Операционная система VMS имеет доступ к одному или нескольким онлайн-дискам, каждый из которых содержит полную, независимую файловую систему. Это либо локальное хранилище, либо, в случае кластера, хранилище, совместно используемое с удаленными системами.

В конфигурации кластера OpenVMS нечастные диски являются общими для всех узлов кластера (см. рисунок 1) . В этой конфигурации два системных диска доступны для обоих узлов через сеть, но частный диск не является общим: он монтируется для использования только определенным пользователем или процессом на этой машине. Доступ к файлам в кластере управляется OpenVMS Distributed Lock Manager, неотъемлемой частью файловой системы.

Несколько дисков можно объединить в один большой логический диск или набор томов . Диски также можно автоматически реплицировать в теневые наборы для обеспечения безопасности данных или более высокой производительности чтения.

Диск идентифицируется либо по своему физическому имени, либо (чаще) по логическому имени, определенному пользователем. Например, загрузочное устройство (системный диск) может иметь физическое имя $3$DKA100, но обычно оно обозначается логическим именем SYS$SYSDEVICE.

Файловые системы на каждом диске (за исключением ODS-1) являются иерархическими. Полностью указанное имя файла состоит из имени узла, имени пользователя и пароля, имени устройства, каталога, имени файла, типа файла и номера версии в формате:

УЗЕЛ"имя_аккаунта_пароль"::устройство:[каталог.подкаталог]имя_файла.тип;версия

Например, [DIR1.DIR2.DIR3]FILE.EXTотносится к последней версии FILE.EXTна текущем диске по умолчанию в каталоге [DIR1.DIR2.DIR3].

DIR1является подкаталогом главного файлового каталога (MFD) или корневого каталога и DIR2является подкаталогом DIR1. MFD диска идентифицируется [000000].

Большинство частей имени файла можно опустить, в этом случае они берутся из текущей спецификации файла по умолчанию . Спецификация файла по умолчанию заменяет концепцию «текущего каталога» в других операционных системах, предоставляя набор значений по умолчанию для узла, имени устройства и каталога. Все процессы имеют спецификацию файла по умолчанию, которая включает имя диска и каталог, и большинство процедур файловой системы VMS принимают спецификацию файла по умолчанию, которая также может включать тип файла; TYPEнапример, команда по умолчанию использует « .LIS» в качестве типа файла, поэтому команда TYPE Fбез расширения пытается открыть файл F.LIS.

Каждый файл имеет номер версии, который по умолчанию равен 1, если нет других версий с таким же именем файла (в противном случае на одну больше, чем самая большая версия). Каждый раз, когда файл сохраняется, вместо того, чтобы перезаписывать существующую версию, создается новый файл с тем же именем, но с увеличенным номером версии. Старые версии можно удалить явно, с помощью команды DELETEили PURGE, или, по желанию, старые версии файла можно удалить автоматически, когда будет достигнут предел версииSET FILE/VERSION_LIMIT файла (заданный с помощью ). Таким образом, старые версии не перезаписываются, а сохраняются на диске и могут быть извлечены в любое время. Архитектурное ограничение на номера версий составляет 32767. Поведение управления версиями легко переопределяется, если оно нежелательно. В частности, файлы, которые обновляются напрямую, такие как базы данных, не создают новых версий, если это явно не запрограммировано.

ODS-2 ограничен восемью уровнями подкаталогов и только заглавными буквами, буквенно-цифровыми именами (плюс подчеркивание, тире и знак доллара) длиной до 39,39 символов (39 для имени файла и еще 39 для расширения). ODS-5 расширяет набор символов до строчных букв и большинства других печатных символов ASCII, а также символов ISO Latin-1 и Unicode , увеличивает максимальную длину имени файла и допускает неограниченное количество уровней подкаталогов. При построении имени пути для файла ODS-5, который использует символы, не разрешенные в ODS-2, используется специальный синтаксис "^" для сохранения обратной совместимости; file.tar.gz;1например, файл " " на диске ODS-5 будет называться " file^.tar.gz" — имя файла " file.tar", а расширение " .gz".

Безопасность файлов VMS определяется двумя механизмами: контролем доступа на основе UIC и контролем доступа на основе ACL . Контроль доступа UIC основан на владельце файла и UIC или пользователе, получающем доступ к файлу. Доступ определяется четырьмя группами разрешений:

• Система
• Владелец
• Группа
• Мир

И четыре бита разрешений:

• Читать
• Писать
• Выполнять
• Удалить

Доступ «система» применяется к любому пользователю, чей групповой код UIC меньше или равен параметру SYSGEN( MAXSYSGROUPобычно 8 или 10 восьмеричных ) (например, SYSTEMпользователь); «владелец» и «группа» применяются к владельцу файла и группе пользователей этого пользователя, а «мир» применяется к любому другому пользователю. Существует также пятый бит разрешения, «Управление», который используется для определения доступа к изменению метаданных файла, таких как защита. Эту группу нельзя задать явно; она всегда устанавливается для Системы и Владельца, и никогда для Группы или Мира.

На контроль доступа на основе UIC также влияют четыре системные привилегии, которые позволяют пользователям, обладающим ими, переопределять контроль доступа:

• BYPASS: пользователь неявно имеет RWED-доступ ко всем файлам, независимо от защиты файлов;
• READALL: пользователь неявно имеет доступ R ко всем файлам;
• SYSPRV: пользователь может получить доступ к файлам на основе защиты Системы;
• GRPPRV: пользователь может получить доступ к файлам на основе защиты системы, если его группа UIC совпадает с группой файла.

ACL позволяют назначать дополнительные привилегии на основе пользователя или группы; например, UIC веб-сервера может быть предоставлен доступ на чтение всех файлов в определенном каталоге. ACL могут быть помечены как унаследованные , где ACL файла каталога применяется ко всем файлам в нем. ACL изменяются с помощью EDIT/ACLкоманды и принимают форму пар идентификатор/доступ. Например, запись ACL

(ИДЕНТИФИКАТОР=HTTP$СЕРВЕР,ДОСТУП=ЧТЕНИЕ+ВЫПОЛНЕНИЕ)

позволит пользователю HTTP$SERVERпрочитать и выполнить файл.

Логическое имя — это системная переменная, которая может ссылаться на диск, каталог или файл или содержать другую специфичную для программы информацию. Например, логическое имя SYS$SYSDEVICEсодержит загрузочное устройство системы. Логическое имя обычно ссылается на один каталог или диск, например SYS$LOGIN: , который является домашним каталогом (или каталогами) пользователя; эти логические имена не могут использоваться как истинные имена дисков — SYS$LOGIN:[DIR]FILEэто недопустимая спецификация файла. Однако скрытые логические имена, определяемые DEFINE/TRANSLATION=CONCEALED, могут использоваться таким образом; эти корневые каталоги определяются с завершающим "." в спецификации каталога, следовательно

$ DEFINE/TRANS=СКРЫТЬ ДОМАШНИЙ ДИСК$USERS:[ имя пользователя .]

позволит HOME:[DIR]FILEиспользовать. Более распространенными являются простые логические, которые указывают на определенные каталоги, связанные с некоторым прикладным программным обеспечением, которое может быть расположено на любом диске или в любом каталоге. Следовательно, логический ABC_EXE может указывать на каталог исполняемых программ для приложения ABC, а ABC_TEMP может указывать на каталог временных файлов для того же приложения, и этот каталог может находиться на том же диске и в том же дереве каталогов, что и ABC_EXE, или может находиться где-то на другом диске (и в другом дереве каталогов).

Подобно Unix, VMS определяет несколько стандартных каналов ввода и вывода , доступ к которым осуществляется через логические имена SYS$INPUT, SYS$OUTPUT, SYS$ERRORи SYS$COMMAND. ^[1]

Логические имена не имеют близкого эквивалента в операционных системах POSIX. Они напоминают переменные среды Unix , за исключением того, что они расширяются файловой системой, а не командной оболочкой или прикладной программой. Они должны быть определены перед использованием, поэтому часто многие логические имена определяются в файле команд запуска системы, а также в файлах команд входа пользователя. В VMS логические имена могут ссылаться на другие логические имена (до предопределенного предела вложенности 10) и могут содержать списки имен для поиска существующего имени файла. Вот некоторые часто упоминаемые логические имена:

Ближайшая не-DEC операционная система, поддерживающая концепцию логических имен, — это AmigaOS , через ASSIGNкоманду . Дисковая операционная система AmigaOS, AmigaDOS , которая является портом TRIPOS , имеет некоторое сходство с операционными системами DEC. Например, имена физических устройств следуют шаблону, такому как DF0: для первого гибкого диска, CDROM2: для третьего привода CD-ROM и т. д. Однако, поскольку система может загружаться с любого подключенного привода, операционная система создает назначение SYS: для автоматической ссылки на используемое загрузочное устройство. Также производятся другие назначения, LIBS:, PREFS:, C:, S: и т. д., которые сами ссылаются на SYS:. Конечно, пользователям также разрешено создавать и удалять свои собственные назначения.

Record Management Services — это структурированный уровень ввода-вывода операционной системы VMS. RMS обеспечивает комплексную поддержку программ для управления структурированными файлами , такими как файлы баз данных на основе записей и индексированные файлы. Файловая система VMS в сочетании с RMS расширяет доступ к файлам за пределы простых потоков байтов и обеспечивает поддержку на уровне ОС для различных типов файлов с богатым набором данных. Каждый файл в файловой системе VMS можно рассматривать как базу данных , содержащую ряд записей , каждая из которых имеет одно или несколько отдельных полей . Например, текстовый файл представляет собой список записей (строк), разделенных символом новой строки. RMS — пример файловой системы, ориентированной на записи .

RMS определяет четыре формата записей :

• Фиксированная длина — все записи в файле имеют одинаковую длину.
• Переменная длина — записи различаются по длине, и каждой записи предшествует байт-счетчик, указывающий ее длину.
• Переменная длина записи с контролем фиксированной длины — записи различаются по длине, но им предшествует контрольный блок фиксированной длины.
• Поток - записи различаются по длине, и каждая запись отделена от следующей символом завершения. Текстовый файл является примером файла потокового формата, использующего перевод строки или возврат каретки для разделения записей.

Существует четыре метода доступа к записям или метода извлечения существующих записей из файлов:

• Последовательный доступ — начиная с определенной записи, последующие записи извлекаются по порядку до конца файла.
• Относительный доступ к номеру записи — записи извлекаются по номеру записи относительно начала файла.
• Доступ к адресу файла записи — записи извлекаются непосредственно по их местоположению в файле (RFA или адрес файла записи).
• Индексированный доступ — записи извлекаются по ключу в форме сопоставления ключ-значение .

На уровне диска ODS представляет файловую систему как массив блоков , где блок представляет собой 512 смежных байт на одном физическом диске ( томе ). Дисковые блоки назначаются в кластерах (первоначально 3 смежных блока, но позже увеличенных с большими размерами дисков). Файл на диске в идеале будет полностью смежным, т. е. блоки, содержащие файл, будут последовательными, но фрагментация диска иногда требует, чтобы файл был расположен в несмежных кластерах, и в этом случае фрагменты называются экстентами . Диски могут быть объединены с другими дисками для формирования набора томов , и файлы могут храниться в любом месте этого набора дисков, но большие размеры дисков сократили использование наборов томов, поскольку управление одним физическим диском проще.

Каждый файл на диске Files-11 (или наборе томов) имеет уникальный идентификатор файла (FID), состоящий из трех чисел: номер файла (NUM), порядковый номер файла (SEQ) и относительный номер тома (RVN). NUM указывает, где в INDEXF.SYSфайле (см. ниже) находятся метаданные файла; SEQ — это номер поколения, который увеличивается при удалении файла и создании другого файла с использованием той же записи INDEXF.SYS (чтобы любые висячие ссылки на старый файл случайно не указывали на новый); а RVN указывает номер тома, на котором хранится файл при использовании набора томов.

Структурная поддержка тома ODS обеспечивается файлом каталога — специальным файлом, содержащим список имен файлов, номеров версий файлов и связанных с ними FID, аналогично каталогам VSAM в MVS и каталогам в файловых системах Unix и NTFS . В корне структуры каталогов находится главный файловый каталог (MFD), корневой каталог, который содержит (прямо или косвенно) каждый файл на томе.

На верхнем уровне файловой системы ODS находится главный файловый каталог (MFD), который содержит все файлы каталогов верхнего уровня (включая себя) и несколько системных файлов, используемых для хранения информации о файловой системе. На томах ODS-1 используется двухуровневая структура каталогов: каждый идентификационный код пользователя (UIC) имеет связанный с ним каталог файлов пользователя (UFD) в форме [GROUP.USER]. На томах ODS-2 и более поздних томах расположение каталогов в MFD является свободным, с учетом ограничения на вложенность каталогов (8 уровней на ODS-2 и неограниченно на ODS-5). На многотомных наборах MFD всегда хранится на первом томе и содержит подкаталоги всех томов.

В ODS MFD присутствуют следующие системные файлы:

• INDEXF.SYS;1—Индексный файл
• BITMAP.SYS;1— Хранение файла растрового изображения
• BADBLK.SYS;1—Файл с плохим блоком
• 000000.DIR;1—Сам файл каталога MFD
• CORIMG.SYS;1— Основной файл изображения
• VOLSET.SYS;1— Файл списка набора томов (только ODS-2/5)
• CONTIN.SYS;1—Продолжение файла (только ODS-2/5)
• BACKUP.SYS;1— Резервное копирование файла журнала (только ODS-2/5)
• BADLOG.SYS;1—Ожидаемый плохой блок (только ODS-2/5)
• SECURITY.SYS;1—Профиль безопасности тома (только ODS-2/5)
• QUOTA.SYS;1—Файл квот (необязательно и доступно только в ODS-2/5)
• GPT.SYS;1— Таблица разделов GUID (GPT) (загрузочные структуры OpenVMS I64 EFI, необязательно в OpenVMS Alpha)

Обратите внимание, что сама реализация файловой системы ссылается на эти файлы не по имени, а по их идентификаторам файлов, которые всегда имеют одинаковые значения. Таким образом, INDEXF.SYS всегда является файлом с NUM = 1 и SEQ = 1.

Индексный файл содержит самую основную информацию о наборе томов Files-11.

Существует две организации INDEXF.SYS: традиционная организация и организация, используемая на дисках с GPT.SYS; со структурами таблицы разделов GUID (GPT).

При традиционной организации блок 1 — это загрузочный блок , содержащий местоположение первичного образа начальной загрузки , используемого для загрузки операционной системы VMS. Он всегда находится в логическом блоке 0 на диске, чтобы аппаратная прошивка могла его прочитать. Этот блок всегда присутствует, даже на несистемных (незагрузочных) томах.

После загрузочного блока идет первичный домашний блок . Он содержит имя тома , местоположение экстентов, составляющих остаток файла индекса, UIC владельца тома и информацию о защите тома . Обычно существует несколько дополнительных копий домашнего блока, известных как вторичные домашние блоки , которые позволяют восстановить том в случае его потери или повреждения.

На дисках с GPT.SYS, GPT.SYS содержит эквивалент загрузочного блока (известного как Master Boot Record (MBR)), и нет первичного домашнего блока. Все домашние блоки, присутствующие на диске на основе GPT, являются альтернативными домашними блоками. Эти структуры не включены в INDEXF.SYS, и блоки файла INDEXF.SYS не используются.

Остальная часть файла индекса состоит из заголовков файлов , которые описывают экстенты, выделенные для файлов, находящихся на томе, и метаданных файлов, таких как UIC владельца, ACL и информация о защите. Каждый файл описывается одним или несколькими заголовками файлов — может потребоваться больше одного, если файл имеет большое количество экстентов. Заголовок файла представляет собой блок фиксированной длины, но содержит как фиксированные, так и переменные разделы:

• Заголовок содержит NUM и SEQ, информацию о защите (безопасности) и расположение остальной части заголовка файла.
• Раздел ident содержит метаданные учета: имя файла, время создания и изменения, а также время последнего резервного копирования.
• Карта описывает , какие блоки физического диска (экстенты) сопоставляются с каждым виртуальным блоком файла.
• Список контроля доступа содержит информацию ACL для файла.
• Зарезервированная область — это пространство в конце заголовка файла, которое не используется операционной системой. Это может быть использовано для информации, специфичной для клиента или поставщика.
• Последние два байта заголовка представляют собой контрольную сумму предыдущих 255 слов для проверки действительности заголовка.

Если возможно, разделы map и ACL заголовка полностью содержатся в первичном заголовке . Однако, если ACL слишком длинный или файл содержит слишком много экстентов, в первичном заголовке не будет достаточно места для их хранения. В этом случае заголовок расширения выделяется для хранения информации о переполнении.

Заголовок файла начинается с 4 смещений ( IDOFFSET, MPOFFSET, ACOFFSETи ROFFSET). Поскольку размер областей после заголовка фиксированной длины может меняться (например, области карты и ACL), смещения необходимы для определения местоположения этих дополнительных областей. Каждое смещение — это число 16-битных слов от начала заголовка файла до начала этой области.

Если файлу требуется несколько заголовков, номер сегмента расширения ( SEGNUM) содержит порядковый номер этого заголовка, начиная с 0 в первой записи в INDEXF.SYS.

STRUCLEVсодержит текущий уровень структуры (в старшем байте) и версию (в младшем байте) файловой системы; ODS-2 — уровень структуры 2. Увеличение номера версии указывает на изменение, совместимое с предыдущими версиями, которое может игнорироваться старым программным обеспечением; изменения в самом уровне структуры несовместимы.

W_FID(содержащий три значения: FID_NUM, FID_SEQи FID_RVN, соответствующие файлу, последовательности и относительному номеру тома) содержит идентификатор этого файла; EXT_FID(снова состоящий из трех значений) содержит местоположение следующего заголовка расширения, если таковой имеется. В обоих этих значениях RVN указан как 0 для представления «текущего» тома (0 обычно не является допустимым RVN).

FILECHARсодержит несколько флагов, которые влияют на обработку или организацию файла:

• NOBACKUPприводит к игнорированию этого файла при выполнении резервного копирования .
• WRITEBACKвключает кэшированную (отложенную) запись в файл.
• READCHECKзаставляет все чтения файла выполняться дважды и сравниваться для обеспечения целостности данных.
• WRITCHECKприводит к проверке всех записей путем последующего чтения и сравнения.
• CONTIGBзаставляет ОС попытаться выделить хранилище для файла максимально непрерывным образом.
• LOCKEDустанавливается, если файл заблокирован. Если установлено, это означает, что файл не был правильно закрыт после последнего использования, и его содержимое может быть несогласованным.
• CONTIGуказывает, что файл хранится на диске непрерывно; то есть каждый виртуальный блок сопоставляется с логическим (физическим) блоком для некоторой константы .${\displaystyle я}$${\displaystyle я+к}$${\displaystyle к}$
• BADACLустанавливается, если файл имеет недействительный список контроля доступа.
• SPOOLустанавливается, если файл является файлом очереди, например промежуточным файлом, используемым во время печати.
• DIRECTORYустанавливается, если файл является каталогом.
• BADBLOCKустанавливается, если файл содержит плохие блоки.
• MARKDELустанавливается, если файл был помечен для удаления, но все еще используется; он будет удален после закрытия последним пользователем.
• NOCHARGEЕсли этот параметр установлен, пространство, используемое файлом, не будет взято из квоты хранилища владельца.
• ERASEприводит к перезаписи содержимого файла при его удалении.

ACCMODEописывает уровень привилегий , на котором должен быть запущен процесс для доступа к файлу. VMS определяет четыре уровня привилегий: пользователь, супервизор, exec и ядро. Каждый тип доступа — чтение, запись, выполнение и удаление — кодируется как 2-битное целое число.

FILEPROTсодержит информацию о дискреционном управлении доступом к файлу. Он разделен на 4 группы по 4 бита в каждой: система, владелец, группа и мир. Бит 0 соответствует доступу на чтение, 1 — на запись, 2 — на выполнение и 3 — на удаление. Установка бита запрещает определенный доступ к группе; очистка разрешает его.

Если заголовок файла является заголовком расширения, BACKLINKон содержит идентификатор файла основного заголовка; в противном случае он содержит идентификатор файла каталога, содержащего основную запись для файла.

• Файл растрового изображения для хранения:BITMAP.SYS

Файл битовой карты отвечает за хранение информации об используемом и доступном пространстве на томе. Он содержит блок управления хранилищем (SCB), который включает сводную информацию, детализирующую ???, и битовую карту, массив битов, указывающий, свободен ли кластер блоков на диске или выделен. В ранних версиях VMS кластер состоял из 3 блоков, но по мере увеличения размеров дисков увеличивался и размер кластера.

• Файл плохого блока:BADBLK.SYS

Файл плохих блоков содержит все известные плохие блоки на физическом томе. Цель — не допустить, чтобы система выделяла их файлам. Этот файл использовался больше в ранние дни, когда диски обычно производились с большим количеством плохих участков на поверхности.

• Файл списка наборов томов:VOLSET.SYS

Список наборов томов расположен на томе 1 набора томов и содержит список меток всех томов в наборе, а также имя тома набора.

• Продолжение файла:CONTIN.SYS

Когда файл в многотомном наборе пересекает границу двух составных томов, в качестве его расширенного заголовка используется файл продолжения, описывающий том, на котором можно найти остальную часть файла.

• Файл квоты:QUOTA.SYS

Файл квот содержит информацию об использовании дискового пространства каждым UIC на томе. Он содержит запись для каждого UIC с выделенным ему пространством на томе, а также информацию о том, сколько места используется этим UIC. ПРИМЕЧАНИЕ: Функция DISK QUOTA является необязательной, и файл будет существовать только в том случае, если эта функция когда-либо была включена.

• Профиль безопасности тома:SECURITY.SYS

Профиль безопасности тома содержит UIC владельца тома, маску защиты тома и список контроля доступа.

• Таблица разделов GUID:GPT.SYS

Этот файл перекрывает и защищает структуры диска MBR (Master Boot Record) и GPT (GUID Partitioning Table), используемые для и прошивкой, совместимой с Extensible Firmware Interface . Этот файл создается по умолчанию во время инициализации диска OpenVMS I64 и опционально создается (с помощью INITIALIZE/GPT) в OpenVMS Alpha.

• Сравнение файловых систем
• NTFS — имеет много структурных и метаданных сходств с Files-11 и почти наверняка концептуально является его производным.

• Эндрю К. Голдштейн (1975-06-19). "Спецификация структуры файлов-11 на диске" (PDF) .
• Эндрю К. Голдштейн (11.01.1985). «Спецификация структуры файлов Files-11 на диске».
• VMS Software, Inc. (август 2019 г.). "Приложение A: Структура диска Files-11". Руководство системного менеджера VSI OpenVMS, том 2: Настройка, мониторинг и сложные системы (PDF) .
• Кирби Маккой (1990). Внутреннее устройство файловой системы VMS . Бедфорд, Массачусетс: Digital Press. ISBN 1-55558-056-4.

• Руководство по файловым приложениям OpenVMS
• VMS2Linux