Ссылка DRFSObject.h

О создании содержания

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

Корневой объект для объектов, содержавшихся в иерархии создания содержания Objective C, является DRFSObject. Через DRFSObject файл и объекты папки наследовали основной интерфейс к получению и установке свойств файловой системы, имен и масок. Класс DRFSObject является абстрактным классом, нет никаких методов, доступных для создания DRFSObject непосредственно, Вы создаете DRFile и объекты DRFolder вместо этого.

Реальные и виртуальные объекты

Интерфейс разработан вокруг папки и объектов файла, размечающихся в одном родителе много дочерних иерархий - это должно быть знакомым понятием для любого, кто когда-либо использовал современную файловую систему. Существует два вида объектов в этом API; «реальные» объекты и «виртуальные» объекты и различие важны.

* реальный объект файла или папки соответствует непосредственно файлу или папке на диске. Данные для реального объекта файла прибывают непосредственно из дискового файла. Иерархия под реальным объектом папки соответствует 1:1 иерархии под папкой в дисковой файловой системе.

* виртуальный объект файла или папки не имеет никакого фактического представления на диске. Данные для виртуального объекта файла указаны через API или в функции обратного вызова. Иерархия под объектом виртуальной папки указана через API.

Создание виртуальной иерархии

В иерархии, указанной через этот API, только, виртуальные папки могут быть присвоенными дочерними элементами. Реальные файлы, виртуальные файлы и реальные папки все считают вершинами и могут не иметь дочерних элементов. (Реальные папки могут, конечно, содержать файлы и папки, но файлы и папки указаны дисковым представлением и не могут быть изменены через API, если реальная папка не сделана виртуальной сначала.)

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

Преобразование от реального до виртуального

Реальная папка может быть динамично преобразована в виртуальную папку, когда ее первый уровень дочерних элементов читается и преобразовывается в виртуальную иерархию. Дочерние элементы таким образом создали, все будет реально. Например: реальная папка именованный корень преобразовывается в виртуальную папку. Дисковая папка содержит файл, названный file1 и папкой, названной folder2. После преобразования результатом является виртуальная папка, названная корнем с двумя дочерними элементами: реальный файл file1 и реальная папка folder2.

Базовые имена и собственные имена

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

Начальное базовое имя для реального объекта является именем соответствующего объекта на диске. Когда объект создается, начальное базовое имя для виртуального объекта указано. Базовые имена и для реальных и для виртуальных объектов могут быть изменены с помощью setBaseName: метод.

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

Собственное имя может быть получено и изменено через этот API или может быть оставлено пустым, чтобы быть автоматически сгенерированным от базового имени. Когда собственное имя будет установлено через API, оно будет изменено, чтобы гарантировать, что имя законно согласно определенной файловой системе.

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

Существует два APIs, доступный для получения собственного имени от объекта:

* specificNameForFilesystem: возвращает неизмененное собственное имя, которое использовалось бы, если бы не было никаких конфликтов.

* mangledNameForFilesystem: возвращает измененное собственное имя, искаженное при необходимости, который, как гарантируют, будет уникален среди его одноуровневых элементов в файловой системе.

Ключи файловой системы детализированы в средствах доступа данных Файловой системы. Большинство ключей является прямым; однако, ISO 9660 является особым случаем, так как существует два возможных соглашения о присвоении имен для ISO 9660, уровень 1 (8.3, ограниченный набор символов) и уровень 2 (30 символов, незначительно расширенный набор символов). Вы не можете указать DRISO9660 при получении имени; вместо этого, необходимо явно указать, хотите ли Вы имя уровня 1 или уровня 2 с DRISO9660LevelOne или DRISO9660LevelTwo.

Если имя объекта не конфликтует ни с одним из его одноуровневых элементов, mangledNameForFilesystem: возвратит то же значение как specificNameForFilesystem:. обратное не обязательно верно - один объект может получить фактическое собственное имя, и другие файлы с коллизиями имени будут искажены.

mangledNameForFilesystem: проверит каждый из одноуровневых элементов объекта в иерархии и искажении для разрешения любых конфликтов имени файла, таким образом, это может быть намного более дорогой вызов, чем specificNameForFilesystem: беря в худшем случае O (N^2) время, где N является числом одноуровневых элементов. Когда существует только несколько коллизий, Однако фактическая производительность имеет тенденцию быть намного лучше, ближе к O (N), особенно. mangledNameForFilesystem: имеет преимущество разрешения Вам видеть (и показать пользователю) точные имена, которые были бы сгенерированы на диске, если бы запись была сразу запущена.

Оба specificNameForFilesystem: и mangledNameForFilesystem: будет кэшировать информацию, если это возможно, так, чтобы имена были только сгенерированы и искажены при необходимости. Добавление или удаление дочерних элементов от папки или изменение базового имени или собственного имени на объекте, могут заставить кэшируемые имена дочерних элементов объекта или одноуровневых элементов быть повторно вычисленными.

Свойства и другие метаданные

К свойствам обычно получают доступ так же к именам. Каждый объект имеет общие свойства, применяющиеся к каждой файловой системе, и это может также иметь различные свойства в каждой файловой системе. Например, файл, не имеющий никакой уместности для пользователя MacOS, может быть отмечен невидимый в HFS + дерево, но быть видим в дереве Джолиета.

Свойства, как имена, также дифференцируются файловой системой. Существует один словарь свойств для DRAllFilesystems и один словарь свойств для каждой отдельной файловой системы - DRISO9660, DRJoliet, DRHFSPlus, и т.д.

Свойства для DRAllFilesystems обрабатываются как основное значение, и затем свойства в определенном словаре файловой системы обрабатываются как переопределения.

При получении свойств с propertyForKey:inFilesystem:mergeWithOtherFilesystems: или propertiesForFilesystem:mergeWithOtherFilesystems: можно указать, хотите ли Вы автоматически объединить свойства между указанным словарем файловой системы и «всеми файловыми системами» словарь. Это полезно, если Вы хотите получить действующее значение свойства, потому что это возвратит значение из «всех файловых систем» словарь, если определенная файловая система не присвоит переопределение.

Маски файловой системы

Возможно подавить генерацию определенных элементов в дереве папки. Например, можно хотеть файл приложения MacOS или связаться, чтобы только появиться в HFS + дерево и хотеть, чтобы.EXE файл только появился в дереве Джолиета.

Специфичное для файловой системы утаивание обрабатывается через маску файловой системы. Маска файловой системы является битовым полем, содержащим 1, если объект появится в соответствующей файловой системе, и 0 иначе. Это может использоваться для генерации произвольно сложных деревьев, где в наиболее сложном случае каждая файловая система может теоретически иметь свое собственное уникальное и непересекающееся дерево. (Таким дискам обескураживают, однако, так как они могут сбить с толку пользователю.)

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

Если явная маска является ненулевой, то эффективная маска объекта равна поразрядному AND явной маски объекта и эффективной маски ее родителя.

Если явная маска будет нулем, то объект будет использовать ту же маску в качестве своего родителя. (Другими словами, эффективная маска равна эффективной маске родителя.)

Если корень иерархии не будет иметь явного комплекта масок, то эффективная маска корня и всех его потомков будет нулем.

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

Если эффективная маска объекта будет нулем, то она не будет включена в запись. Главное исключение к этому правилу - когда явная/эффективная маска корневой папки является нулем - когда это произойдет, DiscRecording присвоит маску по умолчанию, обычно та, которая приведет к самому межплатформенному возможному диску.

Если эффективная маска корня будет нулем во время записи, то DiscRecording автоматически выберет маску по умолчанию, обычно та, которая приведет к самому межплатформенному возможному диску.

Некоторые комбинации маски файловой системы имеют особые требования; например, Джолиет основывается на ISO 9660 и требует, чтобы ISO 9660 был включен на, по крайней мере, корневом объекте. (У Вас может все еще быть что-то, появляются в Джолиете, но не ISO 9660, как бы то ни было.) Некоторые комбинации в будущем могут быть взаимоисключающими.

Вы не должны устанавливать явную маску ни для чего кроме корня, если Вы хотите, чтобы все файловые системы имели те же данные. Так как DiscRecording автоматически присвоит маску, если ни один не будет предоставлен, Вы даже не должны устанавливать явную маску для корня.

Перевод символьной ссылки

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

Например, относительная ссылка на «мой длинный, длинный каталог/этот: имя файла with_extension unusual$», будет изменен для содержания чего-то как следующий. Обратите внимание на то, что каждый компонент пути был изменен для приспосабливания правилам целевой файловой системы.

Уровень 1 * ISO 9660: «MYLONGLO/THISISAN.WIT» * уровень 2 ISO 9660: «MY LONG LONG DIRECTORY/THIS: IS AN UNU.WITH_EXTENSION» * Джолиет: «мой длинный, длинный каталог/этот: необычное имя файла with_extension» * HFS +: «мой длинный, длинный каталог/этот: имя файла with_extension unusual$»

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

Сохранение символьной ссылки механизма записи обычно достаточно хорошо для большинства ситуаций, в которых используются символьные ссылки. И, когда исходная файловая система совпадает с целевой файловой системой, символьные ссылки будут сохранены отлично. (Например, HFS + файловая система, сгенерированная от HFS + источник, никогда не должен иметь проблем символьной ссылки.)

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

Это - ожидаемое поведение. В настоящее время единственный способ создать совершенную символьную ссылку, которая, как гарантируют, будет иметь корректный путь во всех файловых системах, состоит в том, чтобы создать виртуальную символьную ссылку с помощью symLinkPointingTo:inFilesystem:.