Модель доступа к файлу

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

Программа, работающая в локальном компьютере, запрашивает и управляет файлами при помощи собственных команд файловой системы того компьютера. Эти команды управляют файлами на диске или другом ресурсе памяти, физически подключенном к локальному компьютеру. Через AFP программа может использовать те же собственные команды файловой системы для управления файлами на совместно используемом ресурсе, находящемся на удаленном компьютере (например, файловый сервер).

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

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

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

AFP поддерживает компьютеры с помощью Mac OS и персональных компьютеров с помощью MS-DOS. AFP может быть расширен для поддержки дополнительных типов компьютеров. Любая реализация AFP должна принять во внимание возможности собственной файловой системы подключенного к сети компьютера и моделировать ее функциональность в общей среде. Другими словами, совместно используемая файловая система должна копировать характеристики файловой системы локального компьютера. Моделирование функциональности собственной файловой системы каждого локального компьютера становится все более и более сложным, поскольку различные типы компьютера совместно используют тот же файловый сервер. Поскольку каждый тип компьютера имеет различные характеристики в способе, которым он управляет файлами, совместно используемая файловая система должна обладать объединенными возможностями всех компьютеров в той же сети.

Три системных компонента составляют AFP:

• структура файловой системы, составленная из ресурсов (таких как файловые серверы, объемы, каталоги, файлы и ветвления), которые адресуемы через сеть. Эти ресурсы вызывают системой файла AFP видимыми объектами. AFP указывает отношение между этими объектами. Например, один каталог может быть родителем другого. Для описаний системы файла AFP видимые объекты посмотрите Структуру файловой системы далее в этой главе.

• Команды AFP, которые являются командами использование локального компьютера для управления структурой файловой системы AFP. Как отмечалось ранее, переводчик отправляет команды файловой системы в файловый сервер в форме команд AFP, или приложение, работающее на локальном компьютере, может сделать команды AFP непосредственно. Каждая команда AFP описана подробно в разделе «Tasks» этого документа.

• алгоритмы связались с командами, указывающими действия, выполняемые командами AFP.

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

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

Структура файловой системы

В этом разделе описываются структуру файловой системы AFP и параметры, связанные с ее системой файла AFP видимые объекты. Эти объекты включают файловый сервер, его объемы, каталоги («папки» в терминологии Mac OS), файлы. и ветвления файла. Этот раздел также описывает древовидную структуру, названную каталогом объема, который является описанием отношений между каталогами и файлами.

Путем отправки команд AFP может клиент AFP

• получите информацию о файловом сервере и других частях структуры файловой системы

• измените информацию, полученную из файлового сервера

• создайте и удалите файлы и каталоги

• получите и храните информацию в отдельных файлах

Следующие разделы описывают систему файла AFP структуры файловой системы видимые объекты.

Объемы

Файловый сервер может сделать один или несколько объемов видимыми клиентам AFP. Каждому объему связали параметры с ним, как перечислено в Битовом массиве Объема. Для обеспечения безопасности на уровне громкости сервер может поддержать дополнительный параметр пароля для любого объема.

FPGetVolParms команда предоставляет дополнительную информацию об объеме. Volume Bitmap перечисляет информацию, которую это может возвратить.

Типы объема

Объем AFP структурирован иерархически. Существует два типа иерархических объемов: фиксированный и переменная. Фиксированный Каталог объем ID содержит многократные каталоги с каждым каталогом, имеющим его собственный постоянный Каталог ID, присваивающийся, когда создается каталог. Каталог ID не используется ни для какого другого каталога во время времени жизни объема, даже если позже удален каталог, которому это присваивается.

Переменный Каталог объем ID также поддерживает уникальность своего Каталога IDs, но отличается от фиксированного Каталога объем ID, в котором это не связывает постоянный Каталог ID с каждым каталогом. Для переменного Каталога объемы ID файловый сервер создает уникальный Каталог ID для каталога каждый раз, когда клиент AFP отправляет FPOpenDir команда. Файловый сервер тогда поддерживает этот Каталог ID, пока клиент не отправляет FPCloseDir команда или сеанс AFP завершаются. Каталог ID, полученный путем отправки FPOpenDir команда к переменному Каталогу объем ID должна использоваться только для того сеанса. Если Каталог ID сохранен и используется для ссылки на каталог в более позднем сеансе, результаты не могут быть предсказаны: команда может привести к сбою, управлять неправильным каталогом, или случайно управлять корректным каталогом.

Табличные 1-2  типы Объема

Значение	Описание
1	Плоский (никакие поддерживаемые каталоги). Осуждаемый.
2	Фиксированный каталог ID.
3	Переменный каталог ID. Осуждаемый.

Типы объема имеют следующие возможности поддержки и ограничения: Персональные компьютеры с помощью MS-DOS могут получить доступ к любому типу объема сервера, потому что понятие Каталога IDs является внешним к их файловым системам. Однако компьютеры Macintosh с помощью иерархической файловой системы (HFS) не могут непосредственно использовать переменный Каталог объемы ID. Macintosh объемами HFS является фиксированный Каталог объемы ID и иерархические объемы на файловом сервере, может быть обработан HFS, только если они - фиксированный Каталог объемы ID. Приложения Mac OS, такие как Средство поиска, сохраняют Каталог IDs и делают не ожидают, что они будут варьироваться.

Каталог объема

Каталог объема является структурой, описывающей расположение ветвящегося дерева файлов и каталогов на фиксированном и переменном Каталоге объемы ID. Каталог не охватывает многократные объемы; клиент AFP видит отдельный каталог объема для каждого объема сервера, который видим клиентам AFP. Рисунок 1-2 показывает пример каталога объема и иллюстрирует его элементы.

Каталог объема содержит каталоги и файлы, переходящие из основного каталога, известного как корень. Эти каталоги и файлы упоминаются как узлы каталога или CNodes (чтобы не быть перепутанным с устройствами в сети, которые также известны как узлы). В древовидной структуре CNodes может быть расположен двумя способами:

• в конце конечности, когда CNode вызывают листом; лист CNode может быть файлом или пустым каталогом

• соединенный сверху и ниже к другим CNodes, заключающим CNode в корпус, вызывается внутренним CNode. Внутренние CNodes всегда являются каталогами

CNodes имеют отношение родителя/потомков. Данный CNode является потомками CNode выше его в дереве каталога, и выше CNode считают его родительским каталогом. Потомки содержатся в родительском каталоге. Единственный CNode, не имеющий родительского каталога, является корневым каталогом.

Когда команда AFP пробивается через каталог объема, может потребоваться только один кратчайший путь от корня до определенного CNode. CNodes вдоль того пути, как говорят, являются наследователями узла назначения, который поочередно вызывают потомком каждого из его наследователей.

IF name type is Short or name is in Short format

THEN check for new name in list of Short Names

    IF name already exists

    THEN return ObjectExists result

    ELSE set object’s Short and Long Names to new name

ELSE { name type is Long OR name is in Long format }

    check for new name in list of Long Names

    IF name already exists

    THEN return ObjectExists result

    ELSE set object’s Long Name to new name

        derive Short Name from Long Name

Обозначение пути к CNode

Для выполнения любого действия с CNode клиент AFP должен определять путь к CNode. AFP обеспечивает правила для указания пути к любому CNode в каталоге объема. CNode (файл или каталог) может быть однозначно указан к серверу идентификаторами, показанными на рисунке 1-3.

ID Объема указывает объем, на котором находится место назначения Кноуд. Каталог ID может принадлежать месту назначения Кноуду (если КНОУД является каталогом), или к любому из его каталогов наследователя, до и включая корневой каталог и родительский каталог корня.

Путь AFP отформатирован как строка Паскаля (байт одной длины, сопровождаемый числом символов, указанных байтом длины) или строка UTF-8 (четырехбайтовый текст, кодирующий подсказку, сопровождаемую двумя байтами длины, сопровождаемыми числом символов, указанных байтами длины). Путь AFP составлен из имен CNode, связанных с прошедшими разделителями нулевого байта. Каждый элемент пути должен быть именем каталога, за исключением последнего, который может быть именем каталога или файла.

Элементами пути может быть Лонг или Краткие названия. Однако данный путь не может содержать смесь Лонга и Кратких названий. Байт типа тракта, указывающий, коротки ли элементы пути все или все Имена Лонга, связан с каждым путем. Путь, состоящий из Кратких названий, имеет тип тракта 1. Путь, состоящий из Имен Лонга, имеет тип тракта 2.

Путь AFP, состоящий из Лонга или Кратких названий, может быть до 255 символов в длину. Единственный нулевой байт как байт длины указывает, что не предоставляется никакой путь. Поскольку байт длины включен в начале строки, каждый элемент пути (имя CNode) не включает индикатор длины. Точно так же путь AFP, состоящий из имен UTF-8–encoded, ограничивается 255 символами Unicode.

Синтаксис пути AFP следует этому абзацу. Звездочка (*) представляет последовательность нуля или больше предыдущих элементов пути; плюс (+) представляет последовательность один или больше предыдущих элементов; <Sep> представляет разделители в пути; вертикальная панель (|) операция ИЛИ; и срок на левой стороне ::= символ определяется как срок (и) на правой стороне.

<Sep> ::= <null-byte>+

<Pathname> ::= empty-string |

    <Sep>*<CNode name>(<Sep><Pathname>*

Синтаксис представляет связь имен CNode, разделенных одним или более нулевыми байтами. Пути могут также запуститься или закончиться строкой нулевых байтов.

Путь может использоваться для пересечения каталога объема в любом направлении. Синтаксис пути позволяет путям или убывать от определенного CNode до его потомков или возрастать от CNode до его наследователей. В любом случае каталог, который является начальной точкой этого пути, определяется отдельно от пути его Каталогом ID. Первый элемент пути является потомком начальной точки каталога. Путь должен быть проанализирован от левого для исправления для получения каждого элемента, использующегося в качестве следующего узла на пути.

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

Для возрастания через объем допустимый путь должен продолжиться от определенного КНОУДА его наследователю. Для возрастания одного уровня в дереве каталога два последовательных нулевых байта должны следовать за именем потомков Кноуда. Для возрастания двух уровней в дереве каталога три последовательных нулевых байта используются в качестве разделителя и т.д.

Определенный объем может убывать и возрасти через каталог объема. Из-за этого много допустимых путей могут относиться к тому же CNode.

Спецификация полного пути может принять много форм. Следующая таблица суммирует различные виды спецификаций пути, которые могут использоваться для пересечения каталога объема, проиллюстрированного на рисунке 1-4. Нуль в квадратных скобках [0] представляет разделитель нулевого байта.

Следующие дескрипторы и примеры относятся к этой таблице и соответствующему каталогу объема, проиллюстрированному на рисунке 1-4. Для упрощения этих примеров CNodes в этом каталоге называют через j, кроме корня, который называют x. Тип тракта проигнорирован в этом примере. Буква v представляет двухбайтовый Объем объема ID. Строки соединяют CNodes; несвязанные строки указывают, что не показаны другие CNodes в этом объеме.

Таблица 1-4 обеспечивает Объем ID, Каталог ID и путь для некоторых демонстрационных спецификаций пути на рисунке 1-4.

Первый пример спецификации пути в Таблице 1-4 содержит Объем ID, Каталог корневого каталога ID, который всегда равняется 2 и пути. В этом случае путь должен содержать имена всех наследователей целевого файла кроме корня, и это должно закончиться именем самого файла. Единственный запаздывающий нулевой байт проигнорирован.

Второй пример содержит Объем ID, Каталог ID наследователя и путь.

Третьим примером является по существу то же как второй пример. Единственный ведущий нулевой байт проигнорирован.

В четвертом примере Каталогом ID является Родитель ID целевого файла. В этом случае, путь должны содержать только имя самого целевого файла.

Пятый пример иллюстрирует иначе для уникального указания убывающего пути к каталогу. Это включает Объем CNODE ID, его Каталог ID и нулевой путь. Эта спецификация пути используется для указания каталога e.

Шестой пример иллюстрирует убывающий путь. Первый CNode в пути является потомками Каталога начальной точки ID. Тогда путь возрастает, хотя родитель e (c) вниз к каталогу g, скопируйте к родителю g (c), и вниз снова к h.

Седьмые шоу возрастающий путь, запускающийся в каталоге c (чей Каталог ID равняется 104), перемещаются вниз к e, и затем возрастают к родителю родителя e (a).

Восьмым примером является особый случай, в котором начальной точкой пути является каталог ID 1, родитель корня. Имя пути должно быть именем имени тома или корневого каталога, соответствующим Объему ID v; кроме того, обход пути выполняется как в других примерах.

Вход в систему AFP

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

После того, как пользователь выбирает сервер AFP для входа в систему, клиент AFP отправляет FPGetSrvrInfo команда для запроса информации о том сервере. Сервер возвращает включающую информацию

• AFP присваивает версию поддержкам сервера

• методы аутентификации пользователей (UAMs) поддержки сервера

• тип машины сервера

• имя сервера

• сетевой адрес сервера

• подпись сервера

• поддерживает ли сервер дополнительную функциональность, такую как переподключение, Откройте Directory, FPCopyFile, FPChangePassword, сохранение паролей и уведомлений сервера

Во время процесса входа в систему AFP клиент AFP говорит сервер, который версию AFP клиент будет использовать для установления соединения и какой UAM это будет использовать для аутентификации пользователя.

Каждая версия AFP уникально описана строкой до 16 символов, названных строкой версии AFP. Строки версии AFP для версий AFP, поддерживаемых AFP 3.x, перечислены в Ссылке файлового протокола Apple.

При работе с различными версиями AFP происходят следующие различия в поведении:

• AFP 2.x — полномочия UNIX и поддержка имени UTF-8 отключен.

• AFP 3.x — корректировки GMT отключены, и все метки времени основываются на GMT.

UAMs, поддерживаемые AFP 3.x и их соответствующие строки, перечислены в Таблице 1-5.

Возможный клиент AFP инициирует процесс входа в систему путем отправки FPLogin или FPLoginExt команда к серверу. Обе команды включают строку версии AFP и строку UAM, которую выбрал клиент. В зависимости от выбранного метода UAM, FPLogin или FPLoginExt команда может включать пользовательскую информацию о входе в систему (такую как имя пользователя или пароль), или последующее FPLoginCont команда может включать такую информацию. Отправка дополнительных FPLoginCont команды могут потребоваться, чтобы завершать аутентификацию пользователя, как описано в Безопасности Файлового сервера AFP.

Если UAM успешно выполняется, сеанс AFP между клиентом AFP и сервером начинается.

После входа в систему клиент AFP должен сразу вызвать FPGetUserInfo видеть, истек ли пароль пользователя.

Как отмечалось ранее, в дополнение к AFP и версиям UAM, которые сервер поддерживает, FPGetSrvrInfo команда возвращает a Flags параметр, биты которого предоставляют дополнительную информацию о сервере, который полезен для клиента AFP. Биты Flags параметр перечислен в Server Flags Bitmap.

Настольная база данных

Для объемов файлового сервера AFP обеспечивает интерфейс, заменяющий прямое использование Средства поиска Файла на рабочем столе. Этот интерфейс необходим, потому что Файл на рабочем столе был разработан для автономной среды и не мог быть совместно использован многочисленными пользователями. Интерфейс AFP к базе данных Desktop заменяет Файл на рабочем столе и может использоваться прозрачно и для локальных и для удаленных объемов.

База данных Desktop используется файловым сервером для содержания информации, необходимой в частности Средству поиска для создания его уникального пользовательского интерфейса, в котором значки используются для представления объектов на дисковом томе. Для создания определенных частей этого интерфейса Средство поиска использует базу данных Desktop для выполнения трех функций:

• связать документы и приложения с определенными значками и сохранить битовые массивы значка

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

• содержать текстовые комментарии связалось с файлами и каталогами

Приложения Macintosh обычно содержат значок, который должен быть выведен на экран для самого приложения, а также других значков, которые будут выведены на экран для документов, которые создает приложение. Эти значки сохранены в ветви ресурсов приложения и в базе данных Desktop. База данных Desktop связывает эти значки с создателем каждого файла ( fdCreator поле в FInfo запись) и тип ( fdType поле в FInfo запись), которые сохранены как часть информации о Средстве поиска файла.

Средство поиска позволяет пользователю Mac OS открывать документ, т.е. выбирать файл и неявно запускать приложение, создавшее файл. Чтобы сделать это, база данных Desktop поддерживает отображение между создателем файла и списком расположений каждого приложения, которому связали того создателя файла с нею. Это отображение упоминается как отображение APPL, потому что все приложения Macintosh имеют создателя файла ‘APPL’. Средство поиска получает первый элемент в списке и пытается запустить приложение. Если по некоторым причинам приложение не может быть запущено (например, если это будет использоваться в настоящее время), то Средство поиска получит следующее приложение из списка базы данных Desktop и попытки что один. Этот список динамично отфильтрован для представления Средству поиска только тех приложений, для которых у клиента AFP есть надлежащие права доступа.

База данных Desktop является также репозиторием для текста комментариев, связанных с файлами и каталогами на объеме. Средство поиска выполнит вызовы к базе данных Desktop, чтобы считать или записать эти комментарии, которые могут быть просмотрены и изменены путем выбора Получить Информационного элемента в меню Finder's File. Комментарии полностью не интерпретируются базой данных Desktop.

Для получения дополнительной информации о Средстве поиска и использовании Файла на рабочем столе, обратитесь к Внутреннему OS X.

Подмонтирование объемов AFP

Начинаясь в версии 10.6, подмонтировании поддержек OS X — монтирование папки в данном sharepoint.

Например, если бы Вы хотите смонтировать папку myfolder в sharepoint, названном mysharepoint на сервере example.com, Вы смонтировали бы его с этим AFP URL:

afp://example.com/mysharepoint/myfolder

До OS X v.10.6, смонтирован сам sharepoint. Начинаясь в версии 10.6, требуемая папка смонтирована.

Это в основном предназначается для поддержки корневых каталогов AFP, в которых у Вас есть «Пользователи» sharepoint с многочисленными пользователями в той папке.