Начинка для яблочного пирога
АрхивМаковое поле (архив)Любая операционная система нуждается в файлах. Принципы построения файловой системы MacOS легли в основу многих других систем. Так как же она устроена?
Файловая система MacOS
В любой операционной системе файловая система выполняет одни и те же задачи: удобно разместить — а впоследствии быстро найти — все эти тысячи и тысячи файлов. Естественно, в MacOS, как в любой модной операционной системе, файловая система и иерархическая, и оптимизированная для работы с дисками огромной емкости (максимальный размер файла составляет 263 байт — теоретически, естественно), и размер кластера даже на многогигабайтных дисках может быть сокращен до половины килобайта, хотя обычно это где-то 1 или 2 Кбайт — в общем, все как у всех, и при нынешней повсеместной многогигабайтности это вполне подходит. Но есть и свои особенности.
Как мы уже говорили, файл в MacOS состоит из двух частей (ответвлений, или форков). Начиная с 9-го поколения, в системе уже появляется поддержка элементов ближайшего будущего — многофорковость и папки-бандлы. Об этом поговорим через несколько месяцев, после выхода пользовательского варианта MacOS X, а пока рассмотрим присущие именно этой файловой системе нюансы.
У файлов НЕТ трехбуквенных расширений!!! С самого 1984 года единственный символ, которого не может быть в имени файла — двоеточие. «Отчет о доходах за январь 1985» — допустимое имя. Ранее имя файла не могло превышать 31 символа, нынешняя инкарнация файловой системы HFS+ увеличивает разрешенную длину имени файла до 255 2-байтовых символов.
Итак, более тридцати (а то и все 255) символов — и никакого расширения?
На самом деле роль расширений играет сразу 2 параметра, которые имеет каждый файл в маковской файловой системе. Каждый из этих параметров представляет собой обыкновенное 32-битовое число без знака, которое принято для удобства передавать комбинациями из 4 символов ASCII. Этот тип-амфибия очень широко применяется в MacOS, для идентификации типов ресурсов, для самых разнообразных дескрипторов в Apple Events (система межпрограммных коммуникаций), для идентификации содержимого буфера обмена данными… Получаются удобные мнемоники, — которые при этом по сути лишь 32-битовые числа. Удобно и практично.
Параметрами файла являются его тип и сигнатура (подпись). Комбинации этих двух параметров обычно соответствует комплект иконок разного разрешения и размера (на все случаи жизни). Тип файла — например, 'TEXT', 'APPL', 'EPSF', 'PDF ' — сообщает о его формате. Существует несколько сотен (тысяч?) стандартных типов файлов. Приведенные выше, соответственно, обозначают файл с простым ASCII текстом, приложение (= .exe), встроенный постскрипт и… PDF. «Нестандартных» же типов никак не менее миллиона. Сигнатура — это такая же четырехсимвольная комбинация, идентифицирующая программу, создавшую данный файл. Например, файлы с типом 'TEXT' создаются, видимо, каждой четвертой программой на свете. Созданные средой разработчика CodeWarrior IDE они имеют сигнатуру 'CWIE', созданные простеньким текстовым редактором SimpleText, бесплатно поставляемым с MacOS — 'ttxt', и так далее.
При открытии файла с сигнатурой, например, 'R*ch', и с типом 'TEXT', первым делом в базе данных рабочего стола (пользователю она не видна) ищется приложение (файл типа 'APPL') с той же сигнатурой (BBEdit 4.5). Если поиск был неудачен, состоится поиск любой (первой попавшейся программы), способной открыть файл типа 'TEXT'. В настоящее время, при надлежащей ее настройке, система может предложить на выбор все приложения, способные открыть наш файл. И даже открыть файл, чьего создателя в системе нет — если известен алгоритм конвертации в один из обслуживаемых форматов.
Увидеть и даже поменять тип любого файла и его сигнатуру можно с помощью сотен различных утилит, например, с помощью того же самого ResEdit. Что будет, если в текстовом файле поменять 'TEXT' на 'APPL'? То же самое, что произойдет, если переименовать dumbtext.txt в superapp.exe в среде Windows.
Пути-дороги
Почему же в именах файлов в MacOS можно применять любые символы, кроме двоеточия? Двоеточие в MacOS выполняет примерно ту же функцию, что косая черта разной ориентации выполняет в UNIX или DOS — разделитель в имени файла, позволяющий определить путь к нему. К примеру, полный путь некоторого файла на «Маке» может выглядеть так: Macintosh HD:990 STL:STL_doc:adaptors.gif. Откуда взялось явное трехбуквенное расширение у приведенного в качестве примера имени файла? А их никто не запрещает использовать. Но и не требует. В операционной системе программы часто используют расширения для своих целей. Например, из Интернета или по почте я часто получаю файлы с двойным расширением, типа a.sit.hqx — и маковский архиватор, обнаружив, что последние четыре буквы имени файла равны «.hqx», понимает, что перед нами маковский файл (с двумя ответвлениями — ресурсов и данных), искусственным образом «спрямленный» и упакованный в обычный немаковский плоский файл. После раскодирования и ликвидации этого окончания мы имеем файл с расширением «.sit» — архив, созданный программой StuffIt. На этом этапе расширение необязательно и добавляется скорее по традиции, поскольку файл уже в маковском формате и снабжен сигнатурой и типом.
Полная (всегда корректная) идентификация файла в MacOS осуществляется с помощью структуры данных FSSpec, в которой идентифицируется папка (директория), в которой находится наш файл, и имя самого файла. Диалоги открытия и сохранения, всевозможные утилиты и процедуры, работающие с файловой системой, предпочитают информацию именно в такой форме.
Ссылки тоже ищут файл не по его пути (просто и неэффективно: при малейшем изменении имени или положения файла ссылки «летели бы») — у каждого файла есть номер и целый букет особенностей, по которым его можно найти. Результат — при перемещении файла в пространстве файловой системы в большинстве случаев ссылка на него остается рабочей.