Автор: @NeoCode. Файл и файловая система – фундаментальные сущности, без которых современные компьютеры немыслимы. Мы привыкли к ним настолько, что порой не задумываемся – а могли бы эти сущности быть другими? Достаточно ли они удобны, эффективны, можно ли их улучшить, и если можно – то как? Насколько удобны и развиты средства для работы с различной метаинфорацией? И какое это все имеет отношение к децентрализованному интернету будущего? Об этом и пойдет разговор в данной статье.

Итак, все современные файловые системы основаны на абстракции файла. Файлы сгруппированы в каталоги (директории, папки), образуя строгую иерархическую систему с единственным «корнем». В основном это всё, что знают о файловой системе большинство пользователей. Да, есть еще и некоторое количество пользователей-«чайников», которые держат файлы на рабочем столе или вообще не задумываются на такие темы, полностью полагаясь на интерфейсы «приложений», которые сами услужливо подсунут нужное. Но в целом, файловое дерево – стандартная абстракция, знакомая большинству. И это единственное, что предоставляют современные файловые системы для структурирования огромных объемов информации. Ну, почти единственное: все-же есть кое-что еще. Дополнительные возможности

Большинство пользователей не использует возможности современных ФС даже наполовину. Например, очень мало кто пользуется симлинками и хардлинками. В распространенных файловых менеджерах просто нет для этого средств (а те в которых есть – нераспространенные). В linux этой возможностью пользуются чаще – в силу более высокой квалификации пользователей, но тем ни менее, такая возможность есть и в Windows. Жесткие и символьные ссылки

Начнем с жестких и символьных ссылок, известных пользователям Linux. На самом деле они есть и в Windows (NTFS), но практически нет инструментов для работы с ними.

Начнем с жестких ссылок. Файл по сути – именованное место на диске. Также у файла есть некий «заголовок» – запись в ФС, где хранится метаинформация – размер, атрибуты, времена создания и изменения, а также указатель на сектора на диске, занимаемые собственно данными. И еще у файла есть запись в структуре директории, где хранится имя файла и указатель на «заголовок» с метаинформацией. Очевидно, что записей в директориях может быть несколько, и все они могут ссылаться на один и тот же «заголовок». А в заголовке обычно заводится счетчик ссылок. При достижении им нуля считается, что файл удален. Именно поэтому операция удаления в некоторых системах называется ‹unlink›.

Символьная ссылка – это другая абстракция. Также как директория, символьная ссылка по сути – особый тип файла, обрабатываемый на уровне ФС. Символьная ссылка содержит путь к некоторому файлу (абсолютный или относительный), таким образом любое обращение к символьной ссылке операционная система обрабатывает как обращение к файлу, на который она указывает. Символьная ссылка, в отличие от жесткой, может указывать и на каталог. Файла или каталога, на который указывает символьная ссылка, может и не быть – это будет обработано как ошибка доступа (например, как если бы вы указали неправильный путь к файлу при открытии).

Как это может помочь на практике? Продвинутые пользователи используют иерархии папок для структурирования информации: создают некую иерархию папок и раскладывают там файлы. А если файл относится сразу к двум и более категориям? Тут поможет жесткая ссылка. Например, некая статья «Сравнение C# и Java» могла бы находиться сразу в двух папках-категориях – и «C#», и «Java». Если же одна категория является подмножеством другой, но также относится к третьей, то для включения ее в третью можно использовать символьную ссылку. Расширенные атрибуты и файловые потоки

У любого файла есть атрибуты. Это размер, время создания, время последнего изменения, ряд битовых признаков (в каждой операционной системе он свой) – например, «только для чтения», биты прав доступа в Linux. Это системные атрибуты, необходимые для того, чтобы сама ОС могла как-то осмысленно работать с файлами. Но как насчет пользовательских атрибутов?

Многие современные ФС поддерживают «расширенные атрибуты» и «альтернативные файловые потоки». Расширенные атрибуты обычно имеют фиксированный и достаточно небольшой размер. Альтернативные файловые потоки («форки», «вилки») могут иметь неограниченный размер, даже превышающий размер самого файла, могут иметь собственные имена. Фактически это возможность присоединять к существующему файлу или даже каталогу дополнительные файлы, невидимые обычными средствами файловой системы. Для простоты я буду дальше пользоваться понятием «расширенные атрибуты», подразумевая также и альтернативные файловые потоки – в этой статье акцент делается не на тонкостях системной реализации, а на самой возможности ассоциировать с файлом пользовательскую метаинформацию.

Расширенные атрибуты применяются на практике. Например, на Хабре есть статья о том, что некоторые браузеры сохраняют в атрибутах url, с которого была сохранена страница или файл. На самом деле это весьма полезная возможность, если бы о ней было известно широкому кругу пользователей. Всегда можно вернуться к сайту, с которого был сохранен файл – за новой версией, дополнительной информацией или другими файлами. Но увы – о возможности практически никому не известно, и она воспринимается как «шпионская».

Основная проблема расширенных атрибутов – в том, что практически нет софта для работы с ними. Да, в Unix есть некие консольные утилиты. Проводник Windows умеет отображать дополнительную метаинформацию (хотя совершенно непонятно, как с помощью Проводника ее туда заносить и редактировать). Говорят, что лучше всего поддержка метаинформации реализована в BeOS/Haiku – но этой системой очень мало кто пользуется. Еще одна проблема – возможная потеря метаинформации при копировании файлов. А если создание копии происходит не штатными средствами ОС, а с помощью прикладного ПО (например, команда «Save as»), то с практически 100% вероятностью расширенные атрибуты не будут сохранены в новый файл. И в целом, пользовательская культура работы с метаинформацией отсутствует, что весьма печально. Метаинформация

Теперь перейдем к собственно метаинформации как таковой.