Войти
A файловая система API - это интерфейс прикладного программирования, через который утилита или пользователь программа запрашивает сервисы файловой системы. Операционная система может предоставлять абстракции для прозрачного доступа к различным файловым системам.
Некоторые API файловой системы могут также включать интерфейсы для операций обслуживания, таких как создание или инициализация файловой системы, проверка целостности файловой системы и дефрагментация.
Каждая операционная система включает API, необходимые для файловые системы, которые он поддерживает. Microsoft Windows имеет API файловой системы для NTFS и нескольких файловых систем FAT. Системы Linux могут включать API для ext2, ext3, ReiserFS и Btrfs, и это лишь некоторые из них.
Некоторые ранние операционные системы были способны обрабатывать только ленточные и дисковые файловые системы. Они обеспечивали самые основные интерфейсы с:
Для большей координации, такой как выделение и освобождение устройства, потребовалось добавление:
Поскольку файловые системы предоставляли больше услуг, больше были определены интерфейсы:
По мере увеличения дополнительных типов файловых систем, иерархической структуры и поддерживаемых носителей дополнительные функции потребовали некоторых специализированных функций:
Многопользовательские системы, требующие API для:
Запись пользовательских данных в файловую систему предназначена для использования непосредственно программой пользователя или библиотекой времени выполнения. Библиотека времени выполнения для некоторых языков программирования может обеспечивать преобразование типов, форматирование и блокировку. Некоторые файловые системы обеспечивают идентификацию записей по ключу и могут включать перезапись существующей записи. Эта операция иногда называется PUT или PUTX(если запись существует)
Чтение данных пользователя, иногда называется GET, может включать направление (вперед или назад) или, в случае файловой системы с ключами, конкретный ключ. Как и при написании библиотеки времени выполнения, может заступиться за пользовательскую программу.
Позиционирование включает в себя настройку местоположения следующей записи. Это может включать пропуск вперед или назад, а также позиционирование в начало или конец файла.
API open может быть явно запрошен или неявно вызван при выполнении первой операции процессом над объектом. Это может привести к установке съемного носителя, установлению соединения с другим хостом и проверке местоположения и доступности объекта. Он обновляет системные структуры, чтобы указать, что объект используется.
Обычные требования для запроса доступа к объекту файловой системы включают:
Может потребоваться дополнительная информация, например
Они запрашиваются через библиотеку языка программирования, которая может обеспечивать координацию между модулями в процессе в дополнение к пересылке запроса в файловую систему.
Следует ожидать, что что-то может пойти не так во время обработки открытия.
В зависимости от языка программирования дополнительные открытые спецификации могут устанавливать модули для обработки этих условий. Некоторые библиотеки указывают библиотечный модуль для файловой системы, позволяющий выполнить анализ, если программа открытия не сможет выполнить какое-либо значимое действие в результате сбоя. Например, если ошибка связана с попыткой открыть необходимый входной файл, единственное действие может заключаться в сообщении об ошибке и прерывании программы. Некоторые языки просто возвращают код, указывающий тип сбоя, который всегда должен проверяться программой, которая решает, о чем сообщить и можно ли продолжить.
Закрыть может привести к отключению или извлечению съемного носителя и обновлению структур библиотеки и файловой системы, чтобы указать, что объект больше не используется. Минимальная спецификация для close ссылается на объект. Кроме того, некоторые файловые системы обеспечивают указание расположения объекта, которое может указывать на то, что объект должен быть удален и больше не является частью файловой системы. Подобно открытому, следует ожидать, что что-то может пойти не так.
Соображения по обработке сбоя аналогичны таковым при открытии.
Информация о данных в файле называется метаданными.
Некоторые метаданные поддерживаются файловой системой, например дата последней модификации (и различные другие даты в зависимости от файловой системы), расположение начала файла, размер файла и, если Утилита резервного копирования файловой системы сохранила текущую версию файлов. Эти элементы обычно не могут быть изменены пользовательской программой.
Дополнительные метаданные, поддерживаемые некоторыми файловыми системами, могут включать в себя владельца файла, группу, к которой принадлежит файл, а также разрешения и / или контроль доступа (т.е. какие доступ и обновления могут выполнять различные пользователи или группы.) и отображается ли файл в обычном режиме, когда каталог указан. Эти элементы обычно можно изменить с помощью утилит файловой системы, которые могут быть выполнены владельцем.
Некоторые приложения хранят больше метаданных. Для изображений метаданные могут включать модель камеры и настройки, использованные для съемки фотографии. Для аудиофайлов метаданные могут включать в себя альбом, исполнителя, который записал запись, и комментарии к записи, которые могут быть специфичными для конкретной копии файла (т. Е. Разные копии одной и той же записи могут иметь разные комментарии при обновлении владельцем файла). Документы могут включать такие элементы, как проверено, одобрено и т. Д.
Переименование файла, перемещение файла (или подкаталога) из одного каталога в другой и удаление файла являются примерами операций, предоставляемых файловой системой для управления каталогами.
Обычно включаются операции с метаданными, такие как разрешение или ограничение доступа к каталогу для различных пользователей или групп пользователей.
В качестве файловой системы используются каталоги, файлы и записи могут быть добавлены, удалены или изменены. Обычно это приводит к неэффективности базовых структур данных. Такие вещи, как логически последовательные блоки, распределенные по носителю таким образом, что вызывают чрезмерное изменение положения, частично используются даже пустые блоки, включенные в связанные структуры. Неполные структуры или другие несоответствия могут быть вызваны ошибками устройства или носителя, несоответствующим временем между обнаружением надвигающейся потери питания и фактической потерей мощности, неправильным завершением работы системы или удалением носителя, а также в очень редких случаях ошибками кодирования файловой системы.
В файловую систему включены специализированные процедуры для оптимизации или исправления этих структур. Обычно они не вызываются пользователем напрямую, а запускаются в самой файловой системе. Внутренние счетчики количества уровней структур, количества вставленных объектов могут сравниваться с порогами. Это может привести к приостановке доступа пользователей к определенной структуре (обычно к неудовольствию пользователя или пользователей), или они могут быть запущены как асинхронные задачи с низким приоритетом, или они могут быть отложены до времени низкой активности пользователя. Иногда эти подпрограммы вызываются или планируются системным менеджером или, как в случае дефрагментации.
API-интерфейс является «уровнем ядра», когда ядро не только предоставляет интерфейсы для разработчиков файловых систем, но это также и пространство, в котором находится код файловой системы.
Она отличается от старой схемы тем, что само ядро использует свои собственные средства для взаимодействия с драйвером файловой системы и наоборот, в отличие от ядра, которое обрабатывает структуру файловой системы, а файловая система - той, которая прямой доступ к оборудованию.
Это не самая чистая схема, но она решает проблемы серьезной перезаписи по старой схеме.
С модульными ядрами он позволяет добавлять файловые системы как любой модуль ядра, даже сторонние. Однако для немодульных ядер требуется перекомпиляция ядра с новым кодом файловой системы (а в ядрах с закрытым исходным кодом это делает невозможным использование сторонних файловых систем).
Unix и Unix-подобные системы, такие как Linux, использовали эту модульную схему.
Существует вариант этой схемы, используемый в MS-DOS (DOS 4.0 и более поздних версий) и совместимый для поддержки CD-ROM и сетевых файловых систем. Вместо добавления кода в ядро, как в старой схеме, или использования средств ядра, как в схеме на основе ядра, он перехватывает все вызовы файла и определяет, следует ли его перенаправить на эквивалентную функцию ядра или необходимо обрабатываться конкретным драйвером файловой системы, а драйвер файловой системы «напрямую» обращается к содержимому диска с помощью низкоуровневых функций BIOS.
API на основе драйверов, когда ядро предоставляет средства, но код файловой системы находится полностью вне ядра (даже не как модуль модульного ядра).
Это более чистая схема, поскольку код файловой системы полностью независим, она позволяет создавать файловые системы для ядер с закрытым исходным кодом и добавления или удаления файловых систем из системы.
Примерами этой схемы являются Windows NT и OS / 2 соответствующие IFS.
В этом 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.
