Broot - это мощный и удобный инструмент для навигации по файловой системе, который предоставляет обзор структуры директорий и позволяет легко находить нужные файлы. Его уникальный подход к отображению дерева каталогов - сбалансированное обрезание папок - помогает пользователям быстро ориентироваться в больших и сложных файловых иерархиях. Естественным, на первый взгляд, кажется желание расширить его возможности и позволить работать не только с файлами и папками на диске, но и с архивами, например zip-архивами, как с виртуальными папками. Однако, несмотря на очевидную привлекательность этой функции, разработчики broot приняли решение не поддерживать навигацию внутри zip-файлов. Почему так случилось? Об этом - подробный рассказ из первых рук.
В основе идеи расширения функционала broot лежало желание с единым подходом просматривать любые деревья - будь то реальные каталоги на диске, записи в архиве или даже специально предоставленные списки путей. Архивы zip устроены так, что их содержимое структурировано как обычные файлы и каталоги, внутри которых можно переходить по вложенным папкам и просматривать файлы. Это создавало определённое сходство с файловой системой и казалось логичным для внедрения в broot. Разработчик взялся за создание прототипа поддержки zip-архивов, основываясь на специальной структуре, позволяющей отличать различные типы узлов и корректно с ними работать. Основным элементом дизайна стало введение категории для каждого пути - btype, которая обозначала, с каким именно типом объекта мы имеем дело: реальный файл, каталог, символическая ссылка, либо корень zip-архива или его файл/каталог внутри.
Такая классификация позволяла в коде broot точно понимать, как вести себя при работе с тем или иным объектом. В качестве примера была разработана структура BType с несколькими вариантами: RealFile, RealDir, ZipRoot, ZipEntryFile, ZipEntryDir и другими. Для представления пути вместе с типом создались структуры BPathBuf и BPath, отражающие путь и его btype. Это позволяло API broot обращаться с узлами независимо от того, реальные ли это объекты файловой системы или записи zip-архива. Чтобы получить список детей для директории внутри zip, прототип вырезал часть пути, соответствующую имени архива, открывал сам архив и искал в нём вложенные записи в интересующей директории.
Таким образом, можно было обойтись без постоянного хранения архивов в памяти и обрабатывать их динамически при навигации. Визуально и технически идея выглядела многообещающе. Навыки и знания Rust, на котором разработан broot, позволили быстро собрать прототип, который работал и мог справляться с сотнями архивов без существенных затрат памяти или производительности. Это была привлекательная перспектива, позволяющая расширить область применения программы и сделать её ещё более универсальной и мощной. Тем не менее, заглянув глубже, возникло несколько серьёзных проблем и ограничений, вынудивших отказаться от реализации.
Первой и главной сложностью стало отсутствие случайного доступа к содержимому файлов из архива. В отличие от обычных файлов, которые можно читать по частям и быстро перемещаться по ним по смещению, внутри zip-архива данные упакованы и требуют либо полного разархивирования, либо поэтапного последовательного чтения. Это серьезно замедляло операции, связанные с поиском по содержимому файлов или предпросмотром больших файлов внутри архивов. Для broot, где привычным является возможность открывать даже многогигабайтные логи с молниеносной скоростью, это несоответствие стало критичным. Далее, дополнительные метаданные, такие как права доступа, время изменения и другие свойства файлов, в zip-архивах либо доступны не полностью, либо вовсе отсутствуют.
Важно понимать, что broot отображает и ориентируется на реальную файловую систему, где эти атрибуты играют существенную роль и помогают пользователю ориентироваться и принимать решения. Для архивов это создаёт неоднородность и своеобразные "дырки" в интерфейсе. Самая сложная техническая и концептуальная трудность возникла при реализации так называемых "глаголов" (verbs) - настраиваемых действий пользователя с файлами и каталогами, таких как перемещение, копирование, удаление, открытие и другие. В случае обычных файлов все операции имеют однозначный и предсказуемый смысл, работа с архивами же требует совершенно иных деликатных подходов: можно ли переместить файл внутри архива? А если переместить файл из архива в папку? Или наоборот? Как поведёт себя удаление? Аналогичные вопросы возникают для любых пользовательских сценариев. Такое усложнение породило необходимость создавать специальные фильтры для работы с разными типами файлов, вводить множество дополнительных проверок и усложнять логику работы программы.
Это противоречило идеям простоты, открытости и понятности, которыми руководствуется разработчик broot. К тому же усложнение архитектуры угрожало стабильности и скорости работы программы. В итоге создался парадокс: несмотря на то что технически возможно реализовать навигацию внутри zip, это идёт в разрез с основной философией проекта. Broot позиционируется как инструмент для эффективного, простого и интуитивного управления реальной файловой системой с акцентом на скорость и удобство. Добавление поддержки zip-путей ухудшало ключевые качества, превращая программу в нечто более комплексное, но менее удобное и логичное.
Разработчик пришёл к выводу, что попытка "универсализации" за счёт расширения типа поддерживаемых деревьев - хотя и привлекательна со стороны идеи - ведёт к ценностным потерям приложения. Суть broot - работать с понятными файловыми объектами, поддерживая полный набор операций и Быстрый доступ к содержимому. Поддержка сложных вложенных абстракций и виртуальных объектов, таких как архивы, нарушает эту концепцию. Отказ от реализации функции навигации по zip-архивам был осознанным и даже освобождающим решением. Благодаря тому, что проект является открытым и ведётся одним человеком, не было необходимости оправдываться перед кем-либо, и можно было быстро прекратить малоэффективное направление работы.
Такая гибкость в экспериментировании, проверке идей и их последующей корректировке является редкостью и значительным преимуществом для разработки проекта. Выводы из этой истории важны не только для пользователей broot, но и для всех, кто разрабатывает программное обеспечение с упором на стабильно-предсказуемую работу. Инновации требуют экспериментов, но при этом важно знать меру и вовремя отказаться от непродуктивных идей. При расширении функционала всегда стоит помнить о первоначальной миссии программы и не жертвовать главным ради мнимой универсальности. Таким образом, broot остаётся инструментом с фокусом на реальную файловую систему и эффективную работу с ней.
Несмотря на привлекательность и кажущуюся простоту задачи, навигация по zip-архивам - слишком сложная и запутанная особенность, которая не соответствует духу и основным требованиям программы. Более того, разработчик открыт к любым предложениям и сотрудничеству, но предпочитает сохранять определённую ясность архитектуры и удобство использования, что делает broot уникальным и востребованным решением для многих пользователей. .
