Мне не нравится, как устроена юниксовая файловая система с точки зрения пользователя, будь то обычный юзер или программист, который пишет что-то для других.
Файлы могут находиться только в директории, но не внутри другого файла. А я иногда хочу вставить файл-картинку в большой документ так, чтобы файловая система знала об этом. В какой бы программе я потом ни захотел скопировать этот документ, картинка скопируется вместе с ним, аналогично тому, как сейчас копируются вложенные папки и файлы.
Файл может находиться только в одной директории. Но иногда хочется положить что-нибудь сразу в несколько папок (такие папки можно называть тегами). Ни жесткие, ни символические ссылки не годятся в качестве полноценной реализации тегов, потому что работают только в одну сторону: если дан файл, искать все ссылки на него долго и дорого. А чтобы удалить файл или переименовать его во всех папках, нужно как раз найти все указывающие на него ссылки.
Внутри файлов нет стандартной структуры, которую понимали бы универсальные утилиты. Например, всякие метаданные хранятся в том же файле, что и основное содержимое. Простая проверка, отличаются ли две аудиозаписи звуком или только ID3-тегами вроде автора и названия, превращается в приключение. Без детального знания формата аудиофайла мне не удастся воспользоваться готовой утилитой для сравнения файлов.
Тип и формат файла принято угадывать либо из расширения, которое вообще-то является частью имени, либо эвристически по содержимому. На разных машинах одно и то же расширение может означать разные типы файлов. Расширение можно перепутать, забыть или специально изменить на неправильное. Эвристики иногда ошибаются, и они тем более не рассчитаны на то, что кто-то захочет их специально обмануть. В результате возможны ситуации, когда файл снаружи выглядит как картинка или текст, а внутри там неизвестно что. А как насчет кодировки символов и переводов строк в текстовых файлах? Они тоже угадываются эвристически. Даже если я точно знаю, что это KOI8-R с CRLF-ными переводами строк, я не могу сохранить эти данные вместе с файлом.
Эрик Рэймонд (Eric S. Raymond) писал об отсутствии произвольных файловых атрибутов в «Искусстве программирования для Unix» (глава 20).
В именах файлов запрещен слеш (/). Из-за этого файл нельзя назвать куском текста, взятым из другого места. Например, чтобы сделать имена файлов из адресов веб-страниц или из названий некоторых книг, придется внести в них искажения.
Нет стандартных средств управления версиями, чтобы для каждого объекта хранилась история изменений. Как только какая-нибудь программа сохраняет файл, его предыдущая версия безвозвратно теряется. (Отдельные программы сохраняют предыдущую версию в бэкапном файле, но это ненадолго продлевает ей жизнь — до следующего сохранения). Можно, конечно, загнать свои файлы в систему управления версиями вроде Subversion, но тогда придется вручную сохранять для истории все файлы в процессе редактирования. Это слишком муторно. К тому же некоторые файлы меняются автоматически, когда вы об этом даже не думаете. Настройки, например. Ежечасные автоматизированные бэкапы — тоже не выход. Они происходят не когда вы закончили работу над документом, а когда попало, да и жрут слишком много места.
Нужно, чтобы управление версиями стало интегрированной частью API операционки. Тогда все редакторы смогли бы писать историю изменений каждого документа с минимальными подсказками со стороны пользователя. И сбылась бы мечта Темы Лебедева: открыть файл, созданный год назад, и выбрать там Undo.
А как насчет атомарных транзакций? Неудавшиеся операции над группами файлов нужно автоматически откатывать к исходному состоянию. В крайнем случае, сохранять исходное состояние в качестве предыдущей версии в истории изменений. Как вам понравится документ, который программа обрезала до 0 байт, чтобы перезаписать, но неожиданно упала?
В общем, файловой системе не хватает в некотором роде базоданности. Не в узком смысле реляционных баз данных, а в более широком, включающем разные способы организации и разные степени структурированности данных. (Веб с гиперссылками — всем известный пример слабо структурированной базы данных).
Будущее где-то рядом. Будьте бдительны.
Atom-поток