Браузер как файловый менеджер

Обновлено: 04.07.2024

Как с Windows- и Android-устройств иметь доступ к данным друг друга, если оба эти устройства находятся в одной локальной сети? Есть масса инструментов из числа стороннего программного обеспечения, решающего эту задачу. Но её также в части доступа к ресурсам Windows можно решить с применением штатного функционала операционной системы. Чтобы с мобильного устройства иметь доступ к расшаренным ресурсам компьютера, нужно в среде Windows настроить для выбранных папок общий доступ в локальной сети.

Для доступа же с компьютера к данным Android-устройства можно поднять на нём FTP-доступ. Рассмотрим, как всё это настраивается и подключается.

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

Если на нашем домашнем компьютере есть медиатека из подборок хороших фильмов, клипов и музыки на наш вкус, домашних фото, всё это мы можем воспроизводить на Android-устройстве. Находясь вдали от компьютера, но, естественно, будучи в зоне действия локальной сети. Для этого нужно, чтобы и компьютер, и Android-смартфон или планшет были подключены к одной локальной сети, например, обеспечиваемой домашним роутером. Ну и, конечно же, компьютер должен быть активен – не выключен, не погружен в сон или гибернацию. Мы сможем не только копировать и воспроизводить контент с компьютера, настроим доступ к его данным так, чтобы мы могли обмениваться файлами – перемещать в расшаренные папки компьютера файлы с Android-устройства и даже удалять в этих папках ненужное.

Первым делом нам необходимо внести нужные сетевые настройки в среде Windows.

Примечание: ниже приводится настройка сетевого доступа к данным с применением обычного функционала локальных сетей Windows, без использования функции «Домашняя группа», упразднённой в Windows 10. Т.е. приведённые ниже инструкции применимы во всех трёх актуальных версиях Windows – 7, 8.1 и 10.

Идём в панель управления, в раздел «Сеть и Интернет».

Нам нужен центр управления сетями.

Кликаем опцию изменения доп/параметров общего доступа.

В профиле гостевой или общедоступной сети включаем сетевое обнаружение и общий доступ к файлам, как показано на скриншоте.

Далее в профиле всех сетей отключаем общий доступ с парольной защитой. И нажимаем кнопку сохранения изменений.

Следующий этап – расшаривание папок с содержимым, к которому мы хотим иметь доступ с Android-устройства, т.е. предоставление для этих папок общего доступа. Кликаем нужную папку в проводнике Windows, в контекстном меню выбираем пункт предоставления доступа, далее же указываем «Отдельные люди».

И – «Готово».

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

Во вкладке «Безопасность» кликаем группу «Все». Жмём «Изменить».

Ставим в блоке разрешений, в графе «Полный доступ» галочку в столбце «Разрешить». Далее нажимаем «Применить» и «Ок».

Теперь всё – полный доступ на управление данными в расшаренной папке предоставлен. Если доступ понадобится ограничить, проделываем обратные настройки в свойствах папки. А если вообще надо будет прекратить её расшаривание, тогда в контекстном меню в проводнике снова запускаем опцию предоставления доступа, но теперь уже выбираем пункт «Сделать недоступным».

И жмём «Прекратить общий доступ».

Описанным выше образом расшариваем каждую нужную папку с контентом и, если необходимо, настраиваем полный доступ к ней. Что нужно сделать на Android, чтобы подключиться к компьютеру по сети и получить доступ к данным в расшаренных папках? Для этого необходимо установить на устройство файловый менеджер, поддерживающий подключение по локальной сети. Одним из таких является приложение «Файловый менеджер +», оно бесплатное, его можно скачать в Google Play .

В этом приложении жмём иконку «Удалённые службы», далее – «Добавить удалённое место», далее – «Локальная сеть». После непродолжительного сканирования сети увидим наш компьютер. Жмём его.

Вводим имя пользователя компьютера, если есть, пароль, а если его нет, оставляем соответствующее поле пустым. Ставим галочку «Анонимный». Жмём «Ок». Далее увидим все расшаренные папки компьютера.

Ну и, соответственно, сможем получить доступ к их содержимому. В дальнейшем к контенту подключённого сетевого компьютера можем получить доступ оперативно, прямо в меню приложения.

По умолчанию файловый менеджер настроен на воспроизведение отдельных типов данных – видео, музыки, изображений и текстовых файлов - собственными средствами, входящими в состав приложения проигрывателями и просмотрщиками. Они примечательны тем, что предусматривают пролистывание файлов, а для медиа – переход на соседние треки и автовоспроизведение по очереди. Но при необходимости эти средства файлового менеджера можно отключить в настройках и использовать другие, установленные на Android-устройстве.

FTP-доступ к содержимому Android-устройства на компьютере

Получить доступ с компьютера к содержимому Android-устройства можно массой различных способов – через подключение по USB -кабелю, с помощью программ для дистанционного управления, с помощью программ, реализующих доступ только к отдельным расшаренным папкам, с помощью доступа по локальной сети. Каждый из этих способов подключения нужно рассматривать в отдельных материалах. Но раз уж мы при рассмотрении подключения к расшаренным ресурсам компьютера использовали приложение «Файловый менеджер +», в этой публикации стоит упомянуть его возможность поднятия на Android-устройстве локального FTP -сервера. Такая возможность позволит нам полноценно управлять данными смартфона или планшета по типу управления файлами на обычном FTP -сервере.

В главном окне приложения «Файловый менеджер +» жмём «Доступ с ПК». В появившейся далее форме снимаем галочку «Случайный номер порта» и жмём «Пуск». Далее увидим FTP -адрес подключения к Android-устройству на компьютере. В этом же окошке подключения будет кнопка остановки работы FTP -сервера – кнопка «Остановить службу». Она, соответственно, отвечает за прекращение сетевого доступа к данным мобильного устройства.

На компьютере в адресную строку проводника вводим отображающийся в Android-приложении FTP -адрес. Получаем доступ к содержимому гаджета и можем с ним работать как с отдельным устройством информации компьютера.

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

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

Производители предлагают нам телефоны со все большим объемом внутренней памяти, и наши смартфоны постепенно становятся основным местом, где мы храним наши данные, документы, файлы и фотографии. Управлять всеми файлами не так просто. В отличие от iOS в Android, у нас практически неограниченный доступ к внутренней памяти устройства, а смартфоны чаще всего сразу после запуска предлагают свой файловый менеджер.

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

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

ES File Explorer

Стандартная (бесплатная) версия ES File Explorer является своего рода легендарным приложением с более чем 5-ю миллионами отзывов в Google Play Store и средней оценкой 4,5 звезды из 5.

Обновление до версии Pro удаляет рекламные объявления, сопровождающие бесплатную версию, а также предоставляет новые функции, такие как поддержка различных служб облачного хранения.

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

С помощью данного приложения можно перемещать, переименовывать, создавать, делиться, отправлять, добавлять в закладки и создавать ярлыки для файлов. Также возможно работать с файлами RAR, 7Z и Zip, последние из которых могут быть созданы на телефоне с использованием 256-битного шифрования AES для обеспечения максимальной безопасности.

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

В менеджере много других функций поэтому если нужен самый полный и обширный файловый менеджер на Android, ES File Explorer должен быть в верхней части списка.

Менеджер от Google

Собственное приложение Google - Files by Google имеет несколько функций, которые делают его более полезным, чем другие файловые менеджеры. В дополнение к стандартной функции определения местоположения, переименования, удаления или перемещения данных, приложение «Files» также имеет раздел, который может помочь удалить дубликаты или ненужные файлы, занимающие ценное пространство.

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

Используя Files by Google, также можно быстро обмениваться файлами с другими пользователями приложения, даже не имея доступа к Интернету.

Файловый менеджер

Название файлового менеджера может быть и самое простое из возможных, но само приложение делает все, что должен делать файловый менеджер, когда дело доходит до организации и управления папками и контентом. Приложение совместимо с SD-картами, дисками NAS и облачными сервисами Google Drive, OneDrive, DropBox, Box и Yandex. Как и Files by Google, он предлагает возможность удаления ненужных файлов, и как ES Explorer он также оснащен встроенными проигрывателями мультимедийных файлов, и может просматривать изображения с текстом.

Asus File Manager

Asus известен, своим собственным производством устройств с Android. Приложение File Manager (File Explorer) является файловым менеджером, устанавливаемым по умолчанию на устройствах выпускаемых данной компанией. И соответственно, загрузить его можно на любое устройство Android, что приятно, потому что это надежный файловый менеджер.

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

X-plore File Manager

X-plore имеет двойной интерфейс, который позволяет легко передавать файлы между папками, особенно на устройствах с большими экранами. Базовая версия бесплатна, но, если есть желание использовать расширенные функции, такие как выделенные медиаплееры, обмен через Wi-Fi или управление файлами с ПК, надо купить приложения.

Файловых менеджеров много, но есть один, о котором, думаю, будет многим интересно узнать. Ведь он двухпанельный, работает в браузере, оснащён редактором (с подсветкой синтаксиса) и консолью, состоит из клиента и сервера, а написан на JavaScript/Node.js.

Предисловие

Первая компьютерная книга, которую я прочитал была Windows: Лаборатория Мастера. Она рассказывает о разнообразных утилитах под Windows 9x. Некоторых из них уже не существует (Zip Magic 2000, например), другие же активно используются, и главное, разрабатываются по сей день (Total Commander). Больше всего мне понравился раздел про файловые менеджеры. Компьютера у меня еще не было, но уже тогда я понял, что использовать Проводник не серьёзно, и гораздо правильнее и удобнее пользоваться Двухпанельными файловыми менеджерами. Я перепробовал все, что были в книге за каждым компьютером, за которым мне удавалось побывать. Больше всего мне, конечно, понравился Total Commander. Он в своём деле лучший это бесспорно.

Через несколько лет, у меня появился компьютер. Спустя некоторое время, рядом с Windows я установил линукс, и хотел найти что-то подходящее для удобного управления файлами. У меня это не особо получилось. Да, Midnight Commander в *nix лучший, это правда. Но многих функций, к которым я так привык пользуясь Тоталом, в нём не было. Не было их и в графических менеджерах. Одна из таких функций, это перемещение указателя текущего файла во время ввода имени (когда папок очень много, а музыки у меня много — листать список, не самое приятное из занятий).

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

Причины

Несколько лет спустя, устроившись в небольшую компанию, я понял, что попадать за свой компьютер буду значительно реже. И действительно, так сложились обстоятельства, что чаще я работаю за чужими компьютерами. А поскольку привыкать к новому мне не очень легко, я начал всё чаще использовать языки и средства разработки работающие в браузере и не требующие установки, настройки и прочих длительных вещей. Я начал использовать Cloud9, Koding и, конечно, GitHub.

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

Аналоги

Большинство аналогов написаны на php, который мне не особо близок. Большую часть кода я пишу на JavaScript, Поэтому, соответственно, мне хотелось бы видеть больше приложений написанных на языке, который быть может и не лучший, но самый распространённый, это точно.

Веб-файл менеджеры

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

имитируют интерфейс проводника Windows (делая менеджер менее удобным чем проводник);
операции с файлами в основном происходят на разных страницах, что совсем не интерактивно (хотя объяснимо тем, что пишутся менеджеры в основном на серверных языках);
работают крайне медленно (не используют локальное хранилище и прочий HTML5-функционал для ускорения работы, поскольку пишутся на серверном языке, а JavaScript используют лишь для базовых вещей таких, как ajax, и это еще хорошо, если данные пересылаются в json а не кусками html-кода);

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

Двухпанельные файловые менеджеры

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

По началу у меня были идеи продолжить чьи-то начинания, подключиться к проекту, так сказать. Я нашел аналог (к сожалению ссылку уже не вспомню) total commander на SourceForge, с веб-интерфейсом, он был написан на PHP, с которым я в то время игрался. Весь его код был сложен в один файл, и разбираться с таким мне не особо хотелось. К тому же, в те времена, я начал активно интересоваться Node.js, и мне хотелось его попробовать на новом проекте.

Из интересного, что появилось с того времени, могу выделить разве, что Metro Commander. Правда пощупать его возможности нет, поскольку работает он лишь на win8, и не в браузере, а нативно. Но на скриншотах выглядит впечатляюще. В остальном в этом направлении особых движений нету, по крайней мере в местах где я ищу.

Особенности

И так, чем же таким интересным обладает Cloud Commander, что на него стоит обратить внимание? Разберём эти пункты подробнее поскольку это действительно важно.

Из самых интересных особенностей стоит выделить следующие:

Работа в браузере. Это немаловажная особенность, которая влечёт за собой череду сильных и слабых сторон, от которых всё зависит. Главное наверно то, что если ты не пользуешься браузером (такие люди правда бывают?) — это программа точно не для тебя (в прочем, это не так сложно изменить, что видно в следующем пункте).
Клиент-серверная архитектура. Это следует из первого пункта, делать совсем всё что хочется средствами браузера не получиться. Но отсюда вытекает огромный плюс: разделение ответственности (логикой и графикой занимаются разные части приложения, что позволяет, например, написать нативный клиент под любую ОС, не меняя код сервера), что, в свою очередь, позволяет в будущем, переписать часть приложения на другой язык, руководствуясь протоколом связи клиента и сервера (об этом ниже будет больше сказано).
Код написан полностью на JavaScript, это значит, что части кода полностью переиспользуются, и на клиенте, и на сервере, что заставляет серьёзнее относиться к тому, что пишешь. Проектировать код так, что бы он максимально не зависел от среды в которой выполняется, будь-то браузер или node.js.
Возможность работы с отключенным JavaScript в браузере. Большая часть операций будет не доступна, но погулять по дереву файлов, и скачать нужные вещи можно будет будет без проблем.
Модульная структура. С самого начала было понятно: если писать всё с нуля, то можно в итоге ни к чему не прийти. Поэтому лишь основная часть (ядро) написана с нуля. Такой функционал, как: просмотр, редактор, консоль и т.д. Это модули, написанные другими людьми. Любой из них может быть заменён (если перестанет поддерживаться, или если появиться серьёзный аналог), и некоторые (редактор и консоль) уже были заменены, но об этом позже.
Отзывчивый интерфейс. Файловый менеджер будет работать в браузере мобильного телефона и планшета. Если экран не вмещает вторую панель, будет отображаться только одна. И реагировать она будет на тачи, а не клики.
Возможность взаимодействовать с Облачными Сервисами (DropBox, GDrive и т.д.)
Возможность скачивать и загружать файлы с помощью Drag'n'Drop.
Возможность загрузки данных из файла (на рабочем столе) в редактор с помощью Drag'n'Drop.
Возможность менять правила jshint, редактируя файл .jshintrc, что будет влиять на все загружаемые в редактор js-файлы.
Различные оптимизации по ускорению загрузки/выгрузки (localStorage, Diff, zip-сжатие на клиенте). Поскольку большая часть работы — это обмен данными между клиентом и сервером, приняты различные меры позволяющие максимально сократить количество трафика, и соответственно, увеличить скорость обмена информацией (что является самым узким звеном в цепочке).

Отличия

Главным отличием является двухпанельный интерфейс с привычными сочетаниями клавиш. Но это не всё. В противовес другим файловым менеджерам, работающим в браузере, Cloud Commander обладает консолью и редактором.

Редактор поддерживает подсветку синтаксиса больше 110 языков. Формат файла определяется по его расширению. Исходный код Cloud Commander правится в нём же самом (и эта статья пишется тоже в нём).

Консоль позволяет выполнять команды на сервере, и не важно это Linux, Mac OS или Windows. Сервер на котором запущен Cloud Commander управляется с консоли прямо в браузере.

Важным отличием также является Node.js как платформа, на которой работает Файловый Менеджер. Больше никакого php + apache.

Недостатки

Наличие преимуществ подразумевает также наличие недостатков, без этого никак. Самые существенные:

Это фундаментальные недостатки. Если говорить о насущных проблемах, то есть и такие. В редакторе:

Есть проблема с табами, если используется не 4 пробела, а именно таб.
В опере мини всё выглядит очень страшно, а старые IE вообще откинуты.
Нельзя загрузить/скачать папку используя Drag'n'Drop (или скачать сразу несколько файлов).
Нет интеграции с облачными сервисами на уровне сервера (в будущем это вполне может поменяться).
Отсутствует прогресс бар при копировании/перемещении/удалении файлов.
Используются стандартные диалоговые окна (alert, confirm, prompt).

Состав

Как уже было выше сказано, Cloud Commander состоит из клиента и сервера. О клиенте уже немного было сказано, поэтому начнём, наверно, с сервера.

Модули сервера

Сервер может работать без установленных зависимостей, при этом он переходит в режим ограниченного функционирования. В таком режиме не работает консоль, оптимизации js/css/html не выполняются, не работает копирование, перемещение и удаление папок. После установки модулей прописанных в package.json, используются:

веб-сервер express который работает на порядок быстрее, чем встроенный;
модуль minify, который минифицирует js/css/html;
модули для копирования, перемещения, удаления папок;

Общие модули

Некоторые модули работают и на клиенте и на сервере, таким является diff-match-patch, разработанный давно, зато работающий очень стабильно.

Модули клиента

На клиенте список используемых модулей гораздо шире. Это:

Внутреннее устройство

Архиватор

Больше всего вопросов, наверно, вызывает архиватор на клиенте. Он используется для уменьшения размера данных отсылаемых на сервер редактором. Этот режим может быть включен (и выключен) в настройках. На самом деле, как я уже говорил, узкое место в клиент-серверном приложении — это передача данных. Запаковка (и распаковка на сервере), в свою очередь, выполняется чрезвычайно быстро.

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

Local Storage

Загружать данные с сервера тоже нет нужны при каждом открытии файлов. Поэтому, при открытии (файлы) кладутся в localStorage, в месте с sha-1 хешем. И, если хеш изменился (без нашего ведома), файл загружается снова, в другом случае хеш обновляется при каждом сохранении файла. Так же обстоят дела и с директориями. Если опция включена, содержимое директории загружается единожды, и для её обновления нужно нажать Ctrl + R (либо удалить/создать новый файл/папку).

Advanced Module Loading

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

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

Потоки node.js — очень мощный инструмент, который кардинально отличается от того, что есть в других скриптовых языках. В процессе погружения в node.js меня не покидала мысль о том, что можно файлы объединять в поток, и отдавать так, как будто файл один. Я думал, что будут задержки в скорости, но нет. Всё работает как часы, и особых замедлений не ощущается, а вместо этого, появляется возможность не объединять файлы в один, и не загружать их последовательно, а загружать их как один файл.

Эту идею, с недавнего времени, начали продвигать в jsDelivr. И, мне кажется, это правильное направление.

Вкратце: если нужно загрузить файл jquery.js и jquery.fancybox.js, это можно сделать таким образом:

cloudcmd.jit.su/join/lib/jquery.js:lib/fancybox.js
С помощью символа ":" имена файлов отделяются друг-от-друга, таким образом, объединять можно абсолютно что угодно, и на быстродействие сервера это не должно особо влиять, поскольку файлы читаются последовательно, но сразу после чтения отдаются клиенту.

Разработка

О самом приложении сказано достаточно, но есть несколько вещей которые хотелось бы сказать о разработке. Как уже говорилось, Cloud Commander пишется в самом себе.

Проект хостится на гитхабе. В нём есть две ветки: dev и master.

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

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

Непрерывная интеграция и тестирование

После каждого пуша, код отправляется в систему travis.ci, где запускаются прописанные тесты, а также код разворачивается на NodeJitsu и Heroku.

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

Если же на каком-то из сервисов Cloud Commander не отвечает, на сайте, в самом верху, возле ссылок отображаются не зеленые кружки, а красные. Если отвечает долго — желтые.

Task runner

На проекте используется Gulp, который автоматизирует все рутинные действия: проверяет js, css, запускает тесты и т.д.

Коммиты

Однажды мне попалась статья, в которой говорилось о стиле именования коммитов принятых в Angular. На самом деле это очень важный процесс. Изменения, исправления, рефакторинг и прочее имеют свою приставку, а во время релиза коммиты с приставками feature и fix выстаскиваются из истории, и выводятся в определенном виде в ChangeLog , всё это делается одной командой: gulp changelog .

Послесловие

Хочу поблагодарить читателя, за то, что дошел так далеко (даже, если он промотал просто). Надеюсь статья была полезной и интересной. Возможно будет продолжение, поживём — увидим.

Это моя первая статья на хабре, если есть опечатки, предложения, замечания — прошу в личку или в ветку hidden в репозитории. Буду стараться исправляться.

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

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

Тогда у нас и появилась идея сделать 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 кладет в редис задачу со статусом «wait»
Frontend делает синхронный запрос в backend, передавая туда id задачи
Backend принимает задачу, ставит статус «running», делает fork и выполняет задачу в дочернем процессе, сразу возвращая ответ на backend
Frontend просматривает статус задачи или отслеживает изменение каких-либо данных (например, количество скопированных файлов, которое периодически обновляется с Backend).

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

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

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

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

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

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

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

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

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

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

Пример распознавания кодировки и чтения файлов, с комментариями

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

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

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

Решение:
Многозадачность организовали достаточно стандартно, используя модуль 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 пользователя.

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

Установка

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

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

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

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

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

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

Добавить поддержку SSH/SFTP
Добавить поддержку WebDav
Добавить терминал
Добавить возможность работы с Git
Добавить возможность расшаривания файлов
Добавить переключение тем оформление и создание различных тем
Сделать универсальный интерфейс работы с модулями

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

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

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

Читайте также: