Клиент Яндекс.диск Для Linux. Консольный

Сегодня мы представляем долгожданный клиент Яндекс.

Диск для Linux. Можно даже сказать «специально для Хабрахабра», поскольку ни одно упоминание о Диске здесь не обходилось без вопросов о клиенте для Linux. Он имеет весь базовый функционал, который есть у клиентов для OS X и Windows, и даже больше (символические ссылки!), и одна особенность — он консольный.



Клиент Яндекс.
</p><p>
Диск для Linux. Консольный

О том, как он настроен, что именно умеет, а также как именно он устроен и что в нем сложно было сделать, читайте ниже.

Вы можете установить его Здесь .

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

После этого вам нужно вручную запустить команду настраивать .

Мастер настроек позволяет в диалоговом режиме выбрать папку для синхронизации, включить автозапуск при старте системы, настроить работу через прокси-сервер (если вы его, конечно, используете) и авторизоваться на Яндекс.

Диске.

При настройке вручную первое, что вам нужно сделать, это войти в систему.

После этого в папке .

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



Команды

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

  • Синхронизировать запустит демон, синхронизирует все в папке «Диск» и остановит демон.

  • Начинать сделает то же самое, но без остановки демона после завершения синхронизации.

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

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

Работать с папкой диска можно как из терминала, так и из Наутилуса.



Что он может сделать?

Консольный клиент позволяет поделиться файлом или папкой с помощью команды публиковать (если файла нет в папке на диске, перед публикацией он будет скопирован туда).

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

Если случайно был опубликован не тот файл, используйте команду отменить публикацию Вы можете заблокировать доступ к общественному объекту.

В Яндекс.

Диске возможна выборочная синхронизация.

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

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

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

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

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



Как это сделано

Чтобы в дальнейшем код можно было использовать для реализации клиентов для разных операционных систем, было решено написать его на C++.

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

В качестве основных кроссплатформенных библиотек мы взяли Способствовать росту , OpenSSL И JsonCpp , и система контроля версий стала мерзавец .

Клиент Linux был собран с использованием автоконфигурация .

Код писался и отлаживался с помощью KDevelop + console gdb, либо в Qt Creator (в зависимости от предпочтений разработчика).

Взаимодействие с облаком и синхронизация осуществляются с помощью базовой библиотеки Яндекс.

Диск, которую используют десктопные клиенты сервиса.



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

Консольный клиент состоит из двух частей: демона и клиента.

Они общаются через текстовые пакеты, содержащие сообщения json, отправленные через сокеты (сокеты домена unix используются в Linux и Mac OS X).

Асинхронная работа реализована с помощью библиотеки boost::asio. Синхронизация доступа к данным реализована через boost::asio::io\_service::strand, что устраняет проблему одновременного доступа к данным несколькими потоками, а также исключает появление взаимоблокировок.

Для локализации мы используем библиотеку boost::locale. Текст внутри клиента кодируется в utf-8 и при необходимости конвертируется в код, специфичный для каждой операционной системы.

Мониторинг файловой системы в Linux использует inotify, который прекрасно вписывается в асинхронную работу boost::asio.

Как работает синхронизация?

Синхронизация — сердце Яндекс.

Диска, его ключевая особенность.

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

1 .

Мониторинг файловой системы.

Ядро синхронизации Яндекс.

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

Но такая задача, как мониторинг файловой системы, не реализована ни стандартной библиотекой C++, ни даже такими монстрами, как boost. Более того, даже используя «родной» API операционной системы, мы получаем набор событий, специфичный для каждой платформы.

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

Причём набор этих событий различен для каждой поддерживаемой платформы.

Например, Mac OS X может сообщать только о факте какого-то изменения в одном из дочерних каталогов, не детализируя его.

Но Windows и Linux возвращают полный набор, включая создание, удаление, изменение и перемещение объектов.

Хотя практика показала, что событиям на платформе Windows доверять не стоит и самым надежным вариантом остается перечисление каталога после получения оповещения.

2 .

Индексирование локальных файлов и каталогов.

Для контроля целостности и реализации дельта-обновлений файлов ядро синхронизации Яндекс.

Диска использует дайджесты — наборы контрольных сумм файла и отдельных его частей.

Для всего файла вычисляем сильный хеш ША-256 и набор менее постоянных сумм для отдельных блоков.

Каждый файл, расположенный в папке Яндекс.

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

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

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

Диск.

Для поиска дайджестов в хранилище используется уникальный идентификатор файла — inode (размер и время последнего изменения).

К сожалению, этот подход не лишен недостатков.

Например, многие файлы криптоконтейнеров сохраняют время последней модификации неизменным даже после записи.

Наверное, кроме тонкостей работы с символическими ссылками, ничего в листинге каталогов не представляет особого интереса.

Для успешного завершения синхронизации ядро должно обнаружить и исключить циклические ветви из синхронизации.

В общем, символические ссылки — это настоящая головная боль для ядра синхронизации.

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

Например, пакеты приложений Mac OS X очень часто содержат символические ссылки на каталоги системных библиотек, и синхронизировать их с облаком было бы нежелательно — особенно между разными версиями ОС.

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

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

Получение дерева файловой системы облака.

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

Если бы ядру синхронизации приходилось каждый раз проходить по дереву методом ПРОПФИНД , то каждый цикл синхронизации занимал бы неоправданно много времени и создавал бы ненужную нагрузку на канал.

Поэтому в программе Яндекс.

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

.

4 .

Получайте оповещения при изменении файловой системы вашего облака.

Синхронизация файлов в реальном времени требует своевременного уведомления об изменениях файлов в облаке.

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

После недолгих поисков мы остановились на протоколе XMPP. Одна из его реализаций уже давно работает в Яндексе.

Его разработала команда, которая позже создала WebDAV-сервер для проекта Яндекс.

Диск, поэтому сложностей с интеграцией этого протокола не возникло.

Сейчас push-уведомления, обрабатываемые ядром синхронизации, включают в себя не только события, произошедшие непосредственно с файлами или папками в облаке Яндекс.

Диск, но и различные служебные сообщения.

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

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

5 .

Создание списка операций синхронизации.

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

Для этого используется специальный алгоритм сравнения деревьев, который принимает на вход кроме двух упомянутых деревьев еще и третье – последнее синхронизированное.

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

6 .

Обработка очереди операций синхронизации.

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

Это может привести к конфликтующим операциям.

Например, удаление файла в облаке, который был изменен в нем и еще не синхронизирован локально, или изменение файла одновременно локально и в облаке.

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

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

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

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

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

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

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

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

Диск.

Если у вас еще нет Я.

Диска, вы можете его приобрести Здесь и установите для Linux здесь: repo.yandex.ru/yandex-disk .

Теги: #linux #Яндекс #CLI #Яндекс.

диск #консольный клиент

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.