файловый менеджер с открытым исходным кодом

Кросс-платформенный файловый менеджер? Это реальность

Доброе время суток, граждане хабражители! Сегодня открылся для сторонних разработчиков новый open-source проект, кроссплатформенный двухпанельный файловый менеджер. Начну данную статью, пожалуй, с предыстории. Для Windows существует всем известный файловый менеджер Total Commander, выгодно отличающийся от других богатым функционалом, мощной системой плагинов, основанной на Win32 API, глубокой настройкой и многооконным режимом. Для других ОС сравнимых по высоте функционала файловых менеджеров пока не существует. А те, что существуют либо давно не развиваются, либо не поддерживают плагины. И всё было нормально, да однажды я решил почистить свой Debian от накопившегося хлама. Процесс чистки стал представлять собой кучу окон и вкладок терминала с Midnight Commander, кучу вкладок и окон различных редакторов и просмотрщиков, графическая оболочка к архиваторам FileRoller и т.д… «Не дело» — решил я, и 24/06/2013 начал изобретать велосипед сделал git init и запустил MonoDevelop…

Проект развивается силами одного лишь меня в свободное от других дел время, на данный момент набралось чуть более полутора сотен коммитов. И вот, спустя год разработки, проект становится открытым для сторонних разработчиков.

Возможности

FC представляет из себя классический двухпанельный файловый менеджер, в целом похожий на Total Commander и ему подобные. Однако в нём присутствует сравнительно полноценная командная строка а-ля FAR или Midnight Commander. Для работы с нелокальными файловыми системами имеется поддержка плагинов ФС. Плагины ФС обеспечивают и работу командной строки, вдумайтесь, каково это работать по SSH одновременно и с терминалом и с файлами не выходя из файлового менеджера?

В программу встроен комбинированный просмоторщик-редактор (VE), вызываемый по стандартным клавишам F3 и F4 (по F3 редактирование отключается). VE поддерживает подключение плагинов для работы с разными типами файлов. Фишкой VE является командная строка (в чём-то аналогичная Vim), позволяющая с клавиатуры осуществлять широкий спектр действий с файлами, ограниченный только возможностями плагина. К сожалению, на данный момент выбор плагинов не велик. Хотя есть возможность подключать плагины через файлы fsplugins.conf и fcveplugins.conf, отдельных плагинов пока не существует, только встроенные – «Локальные ФС» (file://) и «Простой текст» (*.txt). Интерфейс программы может быть переведён на любой язык мира («локализатор» сейчас в зачаточном состоянии, но задел под это есть), а внешний вид подстроен «под себя» при помощи тем оформления в формате CSS (ограничено возможностями XWT).

Архитектура

FC построен по монолитно-модульной архитектуре. Т.е., есть монолитное ядро, fcmd.exe, обеспечивающее пользовательский интерфейс и загружающее переключаемую часть функционала из плагинов, используя особую прослойку – pluginner.dll. Плагины отвечают за работу с файловыми системами, за просмотр и редактирование файлов, в будущем планируются архиваторные плагины и плагины, модифицирующие пользовательский интерфейс (как в Firefox). Плагины представляют из себя классы, наследуемые от pluginner.IPlugin и хранящиеся либо в DLL-файлах, либо вшитые в fcmd.exe (встроенные плагины). Функции и классы, которые могут использоваться не только FC, но и его плагинами вынесены в pluginner. Так, например, виджет «список файлов», FileListPanel, можно внедрять в плагины VE, где его можно использовать для оперирования с несколькими файлами сразу. В качестве библиотеки UI используется официальный тулкит XWT от разработчиков Mono. Темы оформления представляют собой практически обыкновенные CSS-файлы, обрабатываемые отдельным проектом (но также моего производства), библиотекой µCSS. Панель выбора дисков комбинирована с панелью закладок, хотя простое меню закладок никуда не убиралось. Список дисков на панели дисков-закладок реализован в виде динамической закладки (которые можно добавлять и в меню закладок) «список дисков». Это облегчает редактирование в графическом режиме файла speed dial list, именно так обозван файл списка закладок, выполненный в формате XML.

Функциональность, представленная на данный момент, может показаться недостаточной и крайне сырой, богатой на баги. Это из-за того, что у меня не хватает времени и опыта (ваш покорный слуга – любитель, пишу код, когда нечем заняться). Кроме того, до декабря 2013 г. FC писался на WinForms, после чего, будучи практически законченным, несколько месяцев переписывался на XWT. Но это всё отговорки, главное, что идея постепенно воплощается в реальность!

Планы на ближайшее будущее

В четверг, 19 июня, в 20:00 MSK на канале #fcmd-dev в сети IRC RusNet для всех интересующихся состоится онлайн-конференция по архитектуре проекта и перспективах развития. Успеть здесь отвечать всем у меня возможности нет, уж слишком велика местная аудитория, просьба задавать вопросы и сообщать о найденных багах на IRC и GitHub.
Спасибо каждому из нуля человек за посещение #fcmd-dev. То-ли IRC умерла, то-ли всё и так понятно, то-ли не интересно… суть не меняется. Если что, обращайтесь на GitHub.

Скачать

Клонируйте, развивайте, pull-request’те. Сторонние коммиты крайне приветствуются. Приветствуются и создание багов в трекере (Github Issues), с тестированием в одиночку тоже беда.

Ссылку на оф. сайт и форум проекта дать не могу, VDS за 99 руб/мес, более чем уверен, не потянет хабраэффект, хотя если надо – всё ищется.

Источник

Double Commander – файловый менеджер с открытым исходным кодом

Double Commander – это мощная утилита управления файлами, которая помогает просматривать файлы в двух разных разделах и легко сравнивать каталоги. В статье обсудим какими еще функциями обладает ПО.

О Double Commander

О Double CommanderЕсли вы — постоянный пользователь Linux, согласитесь, что для выполнения повседневных задач требуются разнообразные инструменты.

Например, вам нужен:

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

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

Непосредственно к сути, вы будете рады узнать, что такие инструменты существуют, и это Double Commander.

Double Commander — это двухпанельный файловый менеджер с открытым исходным кодом, который доступен для различных ОС, включая Linux. Он вдохновлен Total Commander, но содержит некоторые новые функции.

О файловых менеджерах для Linux, в этой статье.

Официальный сайт Double Commander.

Возможности Double Commander

Просмотр

Главное окно приложения разделено двумя панелями, расположенными рядом, что позволяет просматривать содержимое двух разных разделов и легко просматривать папки.

Для каждого файла, изображения или папки в списке отображаются такие сведения, как:

Упаковка

Одной из важных функций Double Commander является то, что он позволяет упаковать файлы в ZIP, LZMA, TAR, BZ2, TBZ, GZ и TGZ путем выбора интересующего вас метода сжатия.

К тому же, ПО позволяет:

Сравнение

Более того, программа позволяет сравнивать два файла по их содержимому, изменять формат кодирования для каждого и просматривать все выявленные различия. Эта функция очень полезна для пользователей, которым необходимо сравнивать два документа с одинаковым содержанием, но при этом содержать несколько разных слов или предложений.

Поиск

Функция поиска позволяет найти любимые файлы по размеру, включенному тексту, дате создания. Таким образом, находите конкретные документы в каталоге.

Кроме того, сортируйте по:

Преимущества и недостатки Double Commander

Преимущества

Недостатки

Не позволяет перемещать файлы из одного раздела в другой. Все, что вы можете сделать — это просмотреть, удалить или переименовать два разных раздела.

Установка

sudo apt install doublecmd-gtk

Функции

Сравнение по содержимому

Если у вас есть 2 файла, контент которого требуется проверить на идентичность, вам может помочь функция.

Для этого выделяем 2 файла клавишей Ctrl + ЛКМ, и переходим в «Файлы — Сравнить по содержимому»

Теперь в новом окне выбираем «Действие — Сравнить»

В итоге вы фиксируете совпадающие строки как первого файла, так и второго.

Групповое переименование

Если вам требуется переименовать файлы по определенному шаблону, то вам подходит функция.

Для этого заходим в «Файлы — Групповое переименование», или же просто использовать сочетание клавиш «Ctrl + M»

Чтобы изменить имя напишите в окне «Имя файла». Сверху в графе «Новое имя» вы можете сразу понять как будет выглядеть переименованный файл

Копирование и терминал

Для копирования названия файла используйте сочетание клавиш «Ctrl+Shift+X».

Для открытия терминала есть иконка, находящиеся в верхней панели.

Вывод

Double Commander идеально подходит пользователям, которым необходимо просматривать содержимое двух разных разделов одновременно.

Источник

Web файловый менеджер Sprut.IO в OpenSource

В Бегете мы долго и успешно занимаемся виртуальным хостингом, используем много OpenSource-решений, и теперь настало время поделиться с сообществом нашей разработкой: файловым менеджером Sprut.IO, который мы разрабатывали для наших пользователей и который используется у нас в панели управления. Приглашаем всех желающих присоединиться к его разработке. О том, как он разрабатывался и почему нас не устроили существующие аналоги, какие костыли технологии мы использовали и кому он может пригодиться, расскажем в этой статье.

Зачем изобретать свой файловый менеджер

В 2010 году мы использовали NetFTP, который вполне сносно решал задачи открыть/загрузить/подправить несколько файлов.
Однако, пользователям иногда хотелось научиться переносить сайты между хостингами или у нас между аккаунтами, но сайт был большой, а интернет у пользователей не самый хороший. В итоге, или мы делали это сами (что явно было быстрее), или объясняли, что такое SSH, MC, SCP и прочие страшные вещи.

Тогда у нас и появилась идея сделать WEB двух-панельный файловый менеджер, который работает на стороне сервера и может копировать между разными источниками на скорости сервера, а также, в котором будут: поиск по файлам и директориям, анализ занятого места (аналог ncdu), простая загрузка файлов, ну и много всего интересного. В общем, все то, что облегчило бы жизнь нашим пользователям и нам.

В мае 2013 мы выложили его в продакшн на нашем хостинге. В некоторых моментах получилось даже лучше, чем мы хотели изначально — для загрузки файлов и доступа к локальной файловой системе написали Java апплет, позволяющий выбрать файлы и все сразу скопировать на хостинг или наоборот с хостинга (куда копировать не так важно, он умел работать и с удаленным FTP и с домашней директорией пользователя, но, к сожалению, скоро браузеры не будут его поддерживать).

Прочитав на Хабре про аналог, мы решили выложить в OpenSource наш продукт, который получился, как нам кажется, отличным работающим и может принести пользу. На отделение его от нашей инфраструктуры и приведение к подобающему виду ушло еще девять месяцев. Перед новым 2016 годом мы выпустили Sprut.IO.

Как он работает

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

Sprut.IO состоит из нескольких логических компонентов:
1) web-морда,
2) nginx+tornado, принимающие все обращения из web,
3) конечные агенты, которые могут быть размещены как на одном, так и на многих серверах.

Фактически, добавив отдельный слой с авторизацией и выбором сервера, можно сделать мультисерверный файловый менеджер (как в нашей реализации). Все элементы логически можно поделить на две части: Frontend (ExtJS, nginx, tornado) и Backend (MessagePack Server, Sqlite, Redis).

Схема взаимодействия представлена ниже:

Frontend

Web интерфейс — все достаточно просто, ExtJS и много-много кода. Код писали на CoffeeScript. В первых версиях использовали LocalStorage для кеширования, но в итоге отказались, так как количество багов превышало пользу. Nginx используется для отдачи статики, JS кода и файлов через X-Accel-Redirect (подробно ниже). Остальное он просто проксирует в Tornado, который, в свою очередь, является своеобразным роутером, перенаправляя запросы в нужный Backend. Tornado хорошо масштабируется и, надеемся, мы выпилили все блокировки, которые сами же и наделали.

Backend

Backend состоит из нескольких демонов, которые, как водится, умеют принимать запросы из Frontend. Демоны располагаются на каждом конечном сервере и работают с локальной файловой системой, загружают файлы по FTP, выполняют аутентификацию и авторизацию, работают с SQLite (настройки редактора, доступы к FTP серверам пользователя).

Запросы в Backend отправляются двух видов: синхронные, которые выполняются относительно быстро (например, листинг файлов, чтение файла), и запросы на выполнение каких-либо долгих задач (загрузка файла на удаленный сервер, удаление файлов/директорий и т.п.).

Синхронные запросы — обычный RPC. В качестве способа сериализации данных используется msgpack, который хорошо зарекомендовал себя в плане скорости сериализации/десериализации данных и поддержки среди других языков. Также рассматривали python-специфичный rfoo и гугловский protobuf, но первый не подошел из-за привязки к python (и к его версиям), а protobuf, с его генераторами кода, нам показался избыточным, т.к. число удаленных процедур не измеряется десятками и сотнями и необходимости в выносе API в отдельные proto-файлы не было.

Запросы на выполнение долгих операций мы решили реализовать максимально просто: между Frontend и Backend есть общий Redis, в котором хранится выполняемый таск, его статус и любые другие данные. Для запуска задачи используется обычный синхронный RPC-запрос. Flow получается такой:

Интересные кейсы, которые стоит упомянуть

Загрузка файлов с Frontend

Задача:
Загрузить файл на конечный сервер, при этом Frontend не имеет доступа к файловой системе конечного сервера.

Решение:
Для передачи файлов msgpack-server не подходил, основная причина была в том, что пакет не мог быть передан побайтово, а только целиком (его надо сначала полностью загрузить в память и только потом уже сериализовывать и передавать, при большом размере файла будет OOM), в итоге решено было использовать отдельного демона для этого.
Процесс операции получился следующий:
Мы получаем файл от nginx, пишем его в сокет нашего демона с заголовком, где указано временное расположение файла. И после того, как файл полностью передан, отправляем запрос в RPC на перемещение файла в конечное расположение (уже к пользователю). Для работы с сокетом используем пакет pysendfile, сам сервер самописный на базе стандартной питоновской библиотеки asyncore

Определение кодировки

Задача:
Открыть файл на редактирование с определением кодировки, записать с учетом исходной кодировки.

Проблемы:
Если у пользователя некорректно распознавалась кодировка, то при внесении изменений в файл c последующей записью мы можем получить UnicodeDecodeError и изменения не будут записаны.

Все «костыли», которые в итоге были внесены, являются итогом работы по тикетам с файлами, полученными от пользователей, все «проблемные» файлы мы также используем для тестирования после внесенний изменений в код.

Решение:
Исследовав интернет в поисках данного решения, нашли библиотеку chardet. Данная библиотека, в свою очередь, является портом библиотеки uchardet от Mozilla. Она, например, используется в известном редакторе https://notepad-plus-plus.org

Протестировав ее на реальных примерах, мы поняли, что в реальности она может ошибаться. Вместо CP-1251 может выдаваться, например, «MacCyrillic» или «ISO-8859-7», а вместо UTF-8 может быть «ISO-8859-2» или частный случай «ascii».

Кроме этого, некоторые файлы на хостинге были utf-8, но содержали странные символы, то ли от редакторов, которые не умеют корректно работать с UTF, то ли еще откуда, специально для таких случаев также пришлось добавлять «костыли».

Параллельный поиск текста в файлах с учетом кодировки файла

Задача:
Организовать поиск текста в файлах с возможностью использования в имени «shell-style wildcards», то есть, например, ‘pupkin@*.com’ ‘$* = 42;’ и т.д.

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

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

Решение:
Многозадачность организовали достаточно стандартно, используя модуль multiprocessing и две очереди (список всех файлов, список найденных файлов с искомыми вхождениями). Один воркер строит список файлов, а остальные, работая параллельно, разбирают его и осуществляют непосредственно поиск.

Искомую строку можно представить в виде регулярного выражения, используя пакет fnmatch. Ссылка на итоговую реализацию поиска.

Для решения проблемы с кодировками приведен пример кода с комментариями, там используется уже знакомый нам пакет chardet.

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

Распаковка и создание файловых архивов

Задача:
Дать пользователям возможность создавать архивы (доступны zip, tar.gz, bz2, tar) и распаковывать их (gz, tar.gz, tar, rar, zip, 7z)

Проблемы:
Мы встретили множество проблем с «реальными» архивами, это и имена файлов в кодировке cp866 (DOS), и обратные слеши в именах файлов (windows). Некоторые библиотеки (стандартная ZipFile python3, python-libarchive) не работали с русскими именами внутри архива. Некоторые реализации библиотек, в частности SevenZip, RarFile не умеют распаковывать пустые папки и файлы (в архивах с CMS они встречаются постоянно). Также пользователи всегда хотят видеть процесс выполнения операции, а как это сделать если не позволяет библиотека (например просто делается вызов extractall())?

Решение:
Библиотеки ZipFile, а также libarchive-python пришлось исправлять и подключать как отдельные пакеты к проекту. Для libarchive-python пришлось сделать форк библиотеки и адаптировать ее под python 3.

Создание файлов и папок с нулевым размером (баг замечен в библиотеках SevenZip и RarFile) пришлось делать отдельным циклом в самом начале по заголовкам файлов в архиве. По всем багам разработчикам отписали, как найдем время то отправим pull request им, судя по всему, исправлять они это сами не собираются.

Отдельно сделана обработка gzip сжатых файлов (для дампов sql и проч.), тут обошлось без костылей с помощью стандартной библиотеки.

Прогресс операции отслеживается с помощью вотчера на системный вызов IN_CREATE, используя библиотеку pyinotify. Работает, конечно, не очень точно (не всегда вотчер срабатывает, когда большая вложенность файлов, поэтому добавлен магический коэффициент 1.5), но задачу отобразить хоть что-то похожее для пользователей выполняет. Неплохое решение, учитывая, что нет возможности отследить это, не переписывая все библиотеки для архивов.

Повышенные требования к безопасности

Задача:
Не дать пользователю возможности получить доступ к конечному серверу

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

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

Решение:
Все операции были вынесены, в так называемые, workers (createFile, extractArchive, findText) и т.д. Каждый worker, прежде чем начать работать, выполняет PAM аутентификацию, а также setuid пользователя.

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

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

Установка

Мы пошли по пути наименьшего сопротивления и вместо ручной установки подготовили образы Docker. Установка по сути выполняется несколькими командами:

run.sh проверит наличие образов, в случае если их нет скачает, и запустит 5 контейнеров с компонентами системы. Для обновления образов необходимо выполнить

Остановка и удаление образов соответственно выполняются через параметры stop и rm. Dockerfile сборки есть в коде проекта, сборка занимает 10-20 минут.
Как поднять окружение для разработки в ближайшее время напишем на сайте и в wiki на github.

Помогите нам сделать Sprut.IO лучше

Очевидных возможностей для дальнейшего улучшения файлового менеджера достаточно много.

Как наиболее полезные для пользователей, нам видятся:

Если у вас есть дополнения, что может быть полезно пользователям, расскажите нам о них в комментариях или в списке рассылки sprutio-ru@groups.google.com.

Мы начнем их реализовывать, но не побоюсь этого сказать: своими силами на это уйдут годы если не десятилетия. Поэтому, если вы хотите научиться умеете программировать, знаете Python и ExtJS и хотите получить опыт разработки в открытом проекте — приглашаем вас присоединиться к разработке Sprut.IO. Тем более, что за каждую реализованную фичу мы будем выплачивать вознаграждение, так как нам не придется реализовывать ее самим.

Список TODO и статус выполнения задач можно увидеть на сайте проекта в разделе TODO.

Спасибо за внимание! Если будет интересно, то с радостью напишем еще больше деталий про организацию проекта и ответим на ваши вопросы в комментариях.

Источник