Фонарик спешит на помощь

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

Часть первая. Понять - значит простить

Начнем понимание с простого эксперимента. Создадим тестовый текстовый файлик с понятным названием test.txt и не менее понятным содержимым.

Вызовем окно инспектора (Command-I) свойств файла и обратим внимание на размер. Все верно, 3 байта, в которых уместились наши 3 символа "123"

Теперь в этом же окне инспектора добавим комментарий к файлу. И опять посмотрим на размер.

Что за черт? Информации добавилось, размер файла не изменился. Вы видите суслика? Нет? А он есть! Можно переместить файл в другое место, можно удалить его в корзину и восстановить из нее, можно скопировать по сети и вернуть его обратно. Окно инспектора будет упрямо показывать существование комментария к файлу.

Где прячется проклятый суслик?

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

• Основной поток данных (data fork) - само содержимое файла, наши с вами несчастных 3 байта,
• Поток ресурсов (resource fork)

Правда, существует еще понятие именованных потоков (named forks), но в Mac OS 8.3 — Mac OS X 10.3.9 оно полноценного развития так и не получило, а в версии Mac OS X 10.4 появились расширенные атрибуты, призванные частично компенсировать недостачу.

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

xattr /Users/pasha/Documents/1/test.txt 
com.apple.TextEncoding
com.apple.metadata:kMDItemFinderComment

Получается, что тестовый файл обладает, как минимум, двумя расширенными характеристиками - кодировкой текста и метаданными о комментарии файндера к файлу. Запросим комментарий:

mdls -name kMDItemFinderComment /Users/pasha/Documents/1/test.txt 
kMDItemFinderComment = "комментарий"

Грабельки-с заказывали?

Показательно, что у перевода термина fork на русский есть возможное значение "вилы". Пока вы think different внутри своей песочницы - никаких проблем, но как только понадобится выйти за бордюрчик - жизнь услужливо подставляет нам вышеупомянутые вилы, вернее - грабли.

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

Да что там другие системы? Не все встроенные в Mac OS X утилиты учитывают наличие потоков и атрибутов. Возьмем, к примеру, такую обычную и распространенную вещь как архиватор. Опять же, исторически архиваторы работают только с потоком данных. А как сжать все без потери и передать на другой Mac? Приходится искать обходные пути. Одним из таких путей будет: разложить потоки на отдельные файлы, сжать. При расжатии соединить потоки заново. Приступаем.

Вызываем всплывающее меню на нашем тестовов файле и выбираем сжатие.

Теперь перенесем полученный test.txt.zip в другой каталог и дважды кликнем для распаковки стандартной утилитой из поставки Mac OS X. Ничего необычного, распаковался один единственный текстовый файл. Но давайте взглянем на архив пристальнее. К нашему счастью в комплект поставки системы входит консольный архиватор, наивный по поводу потоков и ресурсов.

unzip -l /Users/pasha/Documents/2/test.txt.zip 
Archive:  /Users/pasha/Documents/2/test.txt.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
        3  03-16-10 00:06   test.txt
        0  03-16-10 10:40   __MACOSX/
      285  03-16-10 00:06   __MACOSX/._test.txt
 --------                   -------
      288                   3 files

Оппа, вот оно! На самом деле внутри архива создался каталог __MACOSX для хранения дополнительных данных и файл ._test.txt, хранящий всякую метаинформацию из неосновных потоков.

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

К сожалению не так все солнечно и в родном королевстве. Вызовем окно инспектора на тестовом файле, извлеченном из архива на предыдущем этапе. Практически мы опять должны увидеть комментарии, как и в исходном файле. Однако на последней системе 10.6.2 со всеми апдейтами эта секция окна инспектора останется чистой. Хотя атрибуты там есть на самом деле. В этом можно убедиться опять при помощи консольных xattr или mdls. Бага, блин! Суслик нагло побеждает.

Аналогичная непонятка возникает и по поводу файлов .DS_Store, которые Finder создает автоматически внутри каждой папки, в которую им заглядывают. Внутри файла хранится всякая метаинформация, т.к. позиции иконок и настройки параметров просмотра. До версии Mac OS X 10.5 там хранились и комментарии Spotlight, но в 10.5 они хранятся и в расширенных атрибутах самого файла, хотя в .DS_Store по-прежнему видны их хвосты. Почему не хранить все это в расширенных атрибутах самой папки - одному богу известно, ну и Джобсу заодно.

Подведем краткий итог: наличие дополнительных файлов при передаче через каналы без поддержки альтернативных потоков есть неизбежное, но жизненно необходимое зло. И с этим надо жить.

Если это не победить, то надо возглавить

Если уж нам расширенные атрибуты даны, давайте научимся этим пользоваться. В качестве примера приведу использование комментариев Spotlight для организации документов.

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

Да, существует довольно много отдельных приложений (Together, iDocuments), целью которых ставится помочь простому пользователю. Но с моей точки зрения, использовать для этого специальный каталогизатор кажется несколько противоестественным. Документы - это не музыка, тут и подход может быть несколько иным, и организация проще.

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

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

Для простоты решим, что все наши документы будут физически храниться в одном каталоге, кучей. А делить мы их будем при помощи комментариев Spotlight. Опять же для примера, выделим несколько категорий, пусть это будет macosx, apple, development. Каждую категорию мы будем обозначать комментарием, который начинается с символа @ (или #, как вам приятнее). Откроем окно инспектора документа и внесем нужные категории. Если их несколько - разделим их пробелами.

Теперь, если открыть каталог Documents в Finder и ввести в строку поиска @development, найдутся все документы из это категории. Но вводить каждый раз наименовании категории напрягает, кроме того под руку может найтись документ с почтовым адресом development@microsoft.com , который нам совсем не нужен. Усовершенствуем технологию.

Открываем каталог Documents, нажимаем Command-F для перехода к окну поиска, раскрываем опцию типа условия и выбираем "Остальное"

В открывшемся диалоге находим и выбираем Комментарии Spotlight, для удобства повторения отмечаем опцию "В меню", OK

Вот теперь в окне поиска можно выбрать поиск по комментариям и ввести необходимую категорию.

При необходимости искать по нескольким категориям одновременно нажимаем на кнопку "+" и добавляем еще один критерий поиска. Осталось нажать на "Save" и сохранить настроенный поиск в виде Smart-папки внутри нашего Documents каталога под соответствующим именем.

Теперь для поиска достаточно зайти в нужный Smart-folder.

И еще один совет для расстановки всех точек над Й: что делать, если нужно организовать расширенный поиск, для примера "@кухня или @рецепты" ??? Все просто: откройте окно инспектора на самой Smart-папке, там будет показан текст запроса к Spotlight на его внутреннем языке. Он доступен для понимания не только роботам. Запрос из окна можно выделить и скопировать. Пригодится.

В данном конкретном случае

(true) && (((kMDItemFinderComment = "@development*"cdw)))

обозначает "все с атрибутом комментарий, содержащим слово @development в любом регистре". Подробнее о языке запросов можно прочесть здесь, но нам это не интересно. Просто заметим выражение раз && два, означающее и раз и два одновременно. Нам нужно или. Изменим запрос на

(((kMDItemFinderComment = "@кухня*"cdw))) || (((kMDItemFinderComment = "@рецепты*"cdw)))

что в переводе значит "кухня или рецепты". Среди типов поиска в "Остальное" есть Raw query, "сырой запрос". Вот туда и можно ввести новый текст

Ой.