API файловой системы — это интерфейс прикладного программирования , через который утилита или пользовательская программа запрашивает службы файловой системы. Операционная система может предоставлять абстракции для прозрачного доступа к различным файловым системам.
Некоторые API файловой системы могут также включать интерфейсы для операций обслуживания, таких как создание или инициализация файловой системы, проверка целостности файловой системы и дефрагментация .
Каждая операционная система включает API, необходимые для поддерживаемых ею файловых систем. Microsoft Windows имеет API файловой системы для NTFS и нескольких файловых систем FAT . Системы Linux могут включать API для ext2 , ext3 , ReiserFS и Btrfs , и это лишь некоторые из них.
Некоторые ранние операционные системы могли работать только с файловыми системами на лентах и дисках . Они предоставляли самые базовые интерфейсы с:
Для большей координации, такой как распределение и освобождение устройств, потребовалось добавить:
Поскольку файловые системы предоставляли больше услуг, было определено больше интерфейсов:
По мере увеличения количества дополнительных типов файловых систем, иерархической структуры и поддерживаемых носителей появились дополнительные функции, требующие некоторых специализированных функций:
Многопользовательским системам требуются API для:
Запись пользовательских данных в файловую систему предоставляется для использования непосредственно пользовательской программой или библиотекой времени выполнения. Библиотека времени выполнения для некоторых языков программирования может обеспечивать преобразование типов, форматирование и блокировку. Некоторые файловые системы обеспечивают идентификацию записей по ключу и могут включать перезапись существующей записи. Эта операция иногда называется PUT или PUTX(если запись существует)
Чтение пользовательских данных, иногда называемое GET, может включать направление (вперед или назад) или в случае ключевой файловой системы — конкретный ключ. Как и в случае с записью, библиотеки времени выполнения могут вмешиваться в пользовательскую программу.
Позиционирование включает в себя настройку местоположения следующей записи. Это может включать пропуск вперед или назад, а также позиционирование в начале или конце файла.
Открытый API может быть явно запрошен или неявно вызван при выдаче первой операции процессом над объектом. Он может вызвать монтирование съемного носителя, установление соединения с другим хостом и проверку местоположения и доступности объекта. Он обновляет системные структуры, чтобы указать, что объект используется.
Обычные требования для запроса доступа к объекту файловой системы включают в себя:
Может потребоваться дополнительная информация, например:
Они запрашиваются через библиотеку языка программирования, которая может обеспечивать координацию между модулями в процессе, а также пересылать запрос в файловую систему.
Следует ожидать, что во время обработки открытия что-то может пойти не так.
В зависимости от языка программирования, дополнительные спецификации в открытом доступе могут устанавливать модули для обработки этих условий. Некоторые библиотеки указывают библиотечный модуль для файловой системы, разрешающий анализ, если открывающая программа не может выполнить какое-либо осмысленное действие в результате сбоя. Например, если сбой произошел при попытке открыть необходимый входной файл, единственным действием может быть сообщение об ошибке и прерывание программы. Некоторые языки просто возвращают код, указывающий тип ошибки, который всегда должен проверяться программой, которая решает, что сообщать и может ли она продолжать.
Close может вызвать демонтаж или извлечение сменного носителя и обновление структур библиотеки и файловой системы, чтобы указать, что объект больше не используется. Минимальная спецификация close ссылается на объект. Кроме того, некоторые файловые системы предоставляют указание расположения объекта, которое может указывать на то, что объект должен быть удален и больше не быть частью файловой системы. Подобно open, следует ожидать, что что-то может пойти не так.
Соображения по устранению сбоев аналогичны тем, что применяются при обрыве связи.
Информация о данных в файле называется метаданными.
Некоторые метаданные поддерживаются файловой системой, например, дата последнего изменения (и различные другие даты в зависимости от файловой системы), местоположение начала файла, размер файла и то, сохранила ли утилита резервного копирования файловой системы текущую версию файлов. Эти элементы обычно не могут быть изменены пользовательской программой.
Дополнительные метаданные, поддерживаемые некоторыми файловыми системами, могут включать владельца файла, группу, к которой принадлежит файл, а также разрешения и/или контроль доступа (т. е. какой доступ и обновления могут выполнять различные пользователи или группы), и виден ли файл обычно, когда каталог указан. Эти элементы обычно изменяются утилитами файловой системы, которые могут быть выполнены владельцем.
Некоторые приложения хранят больше метаданных. Для изображений метаданные могут включать модель камеры и настройки, использованные для съемки фотографии. Для аудиофайлов метаданные могут включать альбом, исполнителя, записавшего запись, и комментарии о записи, которые могут быть специфичны для конкретной копии файла (т. е. разные копии одной и той же записи могут иметь разные комментарии, как и обновления владельца файла). Документы могут включать такие элементы, как проверено, одобрено и т. д.
Переименование файла, перемещение файла (или подкаталога) из одного каталога в другой и удаление файла — примеры операций, предоставляемых файловой системой для управления каталогами.
Обычно включаются такие операции с метаданными, как разрешение или ограничение доступа к каталогу для различных пользователей или групп пользователей.
При использовании файловой системы каталоги, файлы и записи могут добавляться, удаляться или изменяться. Обычно это приводит к неэффективности базовых структур данных. Такие вещи, как логически последовательные блоки, распределенные по носителям таким образом, что это приводит к чрезмерному изменению положения, частично используемые даже пустые блоки, включенные в связанные структуры. Неполные структуры или другие несоответствия могут быть вызваны ошибками устройств или носителей, недостаточным временем между обнаружением надвигающейся потери питания и фактической потерей питания, неправильным выключением системы или извлечением носителя, а в очень редких случаях ошибками кодирования файловой системы.
Специализированные процедуры в файловой системе включены для оптимизации или восстановления этих структур. Обычно они не вызываются пользователем напрямую, а запускаются внутри самой файловой системы. Внутренние счетчики количества уровней структур, количества вставленных объектов могут сравниваться с пороговыми значениями. Это может привести к приостановке доступа пользователя к определенной структуре (обычно к неудовольствию пользователя или затронутых пользователей) или может быть запущено как асинхронные задачи с низким приоритетом или может быть отложено на время низкой активности пользователя. Иногда эти процедуры вызываются или планируются системным менеджером или, как в случае дефрагментации .
API находится «на уровне ядра», когда ядро не только предоставляет интерфейсы для разработчиков файловых систем, но и является пространством, в котором находится код файловой системы.
Она отличается от старой схемы тем, что само ядро использует собственные средства для взаимодействия с драйвером файловой системы и наоборот, в отличие от ядра, которое управляет структурой файловой системы, а файловая система напрямую обращается к оборудованию.
Это не самая ясная схема, но она решает трудности, связанные с серьезным переписыванием старой схемы.
С модульными ядрами это позволяет добавлять файловые системы как любой модуль ядра, даже сторонние. С немодульными ядрами, однако, это требует перекомпиляции ядра с новым кодом файловой системы (а в ядрах с закрытым исходным кодом это делает сторонние файловые системы невозможными).
Unix-системы и Unix-подобные системы, такие как Linux, используют эту модульную схему.
Существует разновидность этой схемы, используемая в MS-DOS (DOS 4.0 и далее) и совместимых с ней системах для поддержки CD-ROM и сетевых файловых систем. Вместо добавления кода в ядро, как в старой схеме, или использования возможностей ядра, как в схеме на основе ядра, она перехватывает все вызовы файла и определяет, следует ли перенаправить его в эквивалентную функцию ядра или его должен обработать определенный драйвер файловой системы, а драйвер файловой системы «напрямую» обращается к содержимому диска, используя низкоуровневые функции BIOS .
API является «драйверным», когда ядро предоставляет возможности, но код файловой системы находится полностью снаружи ядра (даже не как модуль модульного ядра).
Это более чистая схема, поскольку код файловой системы полностью независим, она позволяет создавать файловые системы для ядер с закрытым исходным кодом и добавлять или удалять файловые системы в режиме онлайн.
Примерами этой схемы являются соответствующие IFS Windows NT и OS/2 .
В этом API все файловые системы находятся в ядре, как и в API на основе ядра, но они автоматически захватываются другим API, основанным на драйверах, операционной системой.
Эта схема использовалась в Windows 3.1 для предоставления драйвера файловой системы FAT в 32-разрядном [ требуется ссылка ] защищенном режиме и кэшировании (VFAT), который полностью обходил драйвер DOS FAT в ядре (MSDOS.SYS), а позднее в серии Windows 9x ( 95 , 98 и Me ) для VFAT, драйвера файловой системы ISO9660 (вместе с Joliet), сетевых ресурсов и драйверов файловых систем сторонних производителей, а также для добавления к исходным API DOS API LFN (чтобы драйверы IFS могли не только перехватывать уже существующие API файлов DOS, но и добавлять новые из исполняемого файла 32-разрядного защищенного режима).
Однако этот API не был полностью документирован, и третьи стороны оказались в ситуации «сделай сам», которая была даже хуже, чем в случае с API на основе ядра.
API находится в пользовательском пространстве , когда файловая система не использует напрямую возможности ядра, а обращается к дискам с помощью высокоуровневых функций операционной системы и предоставляет функции в библиотеке , которую ряд утилит использует для доступа к файловой системе.
Это полезно для работы с образами дисков.
Преимущество состоит в том, что файловую систему можно сделать переносимой между операционными системами, поскольку используемые ею высокоуровневые функции операционной системы могут быть такими же общими, как ANSI C, но недостатком является то, что API уникален для каждого приложения, реализующего его.
Примерами такой схемы являются hfsutils и adflib [ постоянная мертвая ссылка ] .
Поскольку все файловые системы (по крайней мере дисковые) нуждаются в эквивалентных функциях, предоставляемых ядром, можно легко перенести код файловой системы с одного API на другой, даже если они относятся к разным типам.
Например, драйвер ext2 для OS/2 — это просто оболочка из VFS Linux в IFS OS/2 и ext2 на основе ядра Linux, а драйвер HFS для OS/2 — это порт hfsutils в IFS OS/2. Существует также проект, который использует драйвер Windows NT IFS для работы NTFS под Linux.