Linux用のYandex.Diskクライアント。 カンチレバー

今日は、待望のLinux用Yandex.Diskクライアントを紹介します。 Linuxのクライアントについての質問なしに、ここでディスクについて言及しただけでは完全ではなかったため、「Habrahabrに特化した」と言うことさえできます。



クライアントがOS XおよびWindows用に備えている基本的な機能をすべて備えており、さらに多くの機能（シンボリックリンク！）があり、1つの機能はコンソールです。







構成方法、実行できること、動作の仕組み、およびその中で行うのが難しかったことについて、以下をお読みください。





ここからインストールできます 。 パッケージをインストールするとすぐに、 yandex-diskコマンドがターミナルに表示され、Yandexクラウドとの通信が継続されます。 その後、 セットアップコマンドを手動で実行する必要があります 。



構成ウィザードを使用すると、ダイアログモードで同期するフォルダーを選択し、システム起動時の自動実行を有効にし、プロキシサーバーを介して作業を構成します（もちろん使用しない限り）、Yandex.Diskにログインできます。 手動で設定する場合、最初に行う必要があるのはログインです。 その後、ホームディレクトリにある.configフォルダーに構成が作成されます。このフォルダーでは、同期フォルダーへのパスを構成できます（コンソールで手動で指定できます）。トークンファイルへのパスを指定し、同期するフォルダーまたは同期しないフォルダーを指定します。プロキシサーバーの設定を規定します。

チーム

準備作業は終了し、チームの1つのデーモンを起動します。 彼らはあなたがファイルやフォルダを同期し、インターネットがある場所でそれらを使用することができます。

• 同期はデーモンを起動し、ドライブフォルダー内のすべてを同期し、デーモンを停止します。
• Startは同じことを行いますが、同期が完了した後にデーモンを停止しません。 起動を使用すると、デーモンは実行されたままになり、ドライブフォルダーで発生したすべての変更が自動的に同期されます。
• ターミナルでstopと入力すると、気になる場合はいつでも実行中のデーモンを停止できます。
• statusコマンドを使用すると、同期カーネルのステータスを確認できます。

ターミナルとNautilusの両方からディスクフォルダーを操作できます。

何ができる

コンソールクライアントでは、 publishコマンドを使用してファイルまたはフォルダーを共有できます（ファイルがディスクフォルダーにない場合は、 公開前にそこにコピーされます）。 ターミナルでリンクが使用可能になり、リンクをたどったユーザーは、公開したファイルまたはフォルダーを表示または保存できるようになります。 誤ったファイルが誤って公開された場合、 unpublishコマンドは公開オブジェクトへのアクセスをブロックできます。



Yandex.Diskでは、選択的な同期が可能です。 excludeコマンドは、フォルダーを同期から除外します。それ以降に行われたすべての変更はクラウドに送信されません。



読み取り専用オプションを使用すると、ファイルをクラウドにアップロードせずにローカルで変更できます。 ローカルの変更と競合が発生した場合、変更は名前が変更されたファイルに保存され、クラウドからの変更が同期されます。 上書きオプションは、ローカルで変更されたファイルを読み取り専用モードで上書きします。



同期コアの最も興味深いイノベーションを自慢せずにはいられません-これからシンボリックリンク同期をサポートします！ コンソールクライアントの使用に関する問題や質問に遭遇した場合は、 manコマンドとhelpコマンドを使用すると、それらを簡単かつ簡単に理解できます。

どうやって

将来、異なるOSのクライアントを実装するためにコードを使用できるように、C ++で記述することが決定されました。 異なるオペレーティングシステムに固有のコードを個別の関数またはクラスに取り出し、各プラットフォームの実装を作成しました。 Boost 、 OpenSSL 、およびJsonCppを主要なクロスプラットフォームライブラリとして採用し、 gitがバージョン管理システムになりました。 Linuxのクライアントはautoconfを使用して構築されました。 コードは、多くのKDevelop +コンソールgdbまたはQt Creator（開発者の好みに応じて）で作成およびデバッグされました。



クラウドとの相互作用と同期は、サービスのデスクトップクライアントが使用するYandex.Diskカーネルライブラリを使用して実行されます。

仕組み

コンソールクライアントは、デーモンとクライアントの2つの部分で構成されています。 それらは、ソケットを介して送信されるjsonメッセージを含むテキストパケットを介して通信します（LinuxおよびMac OS X UNIXドメインソケットが使用されます）。 非同期操作は、boost :: asioライブラリを使用して実装されます。 データアクセス同期は、boost :: asio :: io \ _service :: strandによって実装されます。これにより、複数のストリームのデータへの同時アクセスの問題を考える必要がなくなり、デッドロックの発生もなくなります。



ローカライズには、boost ::ロケールライブラリを使用します。 クライアント内のテキストはutf-8でエンコードされ、必要に応じて各オペレーティングシステムに固有のコードに変換されます。 Linuxのファイルシステムモニタリングでは、boost :: asioの非同期操作に最適なinotifyを使用します。

同期の仕組み

同期は、その主要機能であるYandex.Diskの心臓部です。 ファイルツリーをクラウドと同期するタスクは、いくつかの独立した部分に分かれています。



1 ファイルシステムモニタリング 。 Yandex.Disk同期コアは、サポートされるすべてのプラットフォームでタスクを実行できるポータブルな抽象化として設計および作成されました。 しかし、ファイルシステムの監視などの問題は、標準のC ++ライブラリや、ブーストなどのモンスターによっても実装されていません。 さらに、オペレーティングシステムの「ネイティブ」APIを使用しても、各プラットフォームに固有の一連のイベントを取得します。



ファイルシステムを監視するために、特定のディレクトリ内のイベントを監視し、そのディレクトリで発生したイベントのリストを返す「オブザーバ」インターフェイスが設計されました。 さらに、サポートされるプラットフォームごとに、これらのイベントのセットは異なります。 たとえば、Mac OS Xは、子ディレクトリの1つに何らかの変更があったことを詳細なしで報告することしかできません。 しかし、WindowsとLinuxは、オブジェクトの作成、削除、変更、移動を含む完全なセットを返します。 Windowsプラットフォームのイベントは信頼すべきではなく、最も信頼性の高いオプションは通知を受信した後にディレクトリをリストすることであることが実践により示されていますが。



2 。 ローカルファイルとディレクトリのインデックス作成 。 ファイルのデルタ更新の整合性と実装を制御するために、Yandex.Disk同期コアはダイジェスト（ファイルとその個々の部分のチェックサムのセット）を使用します。 ファイル全体について、安定したSHA-256ハッシュと、個々のブロックの不安定な合計のセットを計算します。 Yandex.Diskフォルダーにあり、例外のリストに含まれていない各ファイルには、インデックスを作成する必要があります。 ただし、SHA-256ハッシュの計算はかなり高価な操作であり、ソフトウェアを起動するたびにハッシュを計算することは許されないリソースの浪費になります。 したがって、ファイルのインデックス作成が完了すると、同期コアは受信したダイジェストを「銀行」に保存します。これは、Yandex.Diskサービスディレクトリにある特別なリポジトリです。 リポジトリ内のダイジェストを検索するには、一意のファイル識別子-iノード（最終変更のサイズと時刻）が使用されます。 残念ながら、このアプローチには欠点がないわけではありません。 たとえば、多くの暗号化コンテナファイルは、記録後も最終変更時刻を変更せずに保持します。



おそらく、シンボリックリンクでの作業の複雑さに加えて、ディレクトリのリストには特に関心がありません。 同期を正常に完了するには、カーネルが循環ブランチを検出して同期から除外する必要があります。



一般に、シンボリックリンクは、同期コアの本当の「頭痛」です。 ファイルシステム内の任意の場所を指すことができ、それらすべてに同じ同期ルールを適用できます。 たとえば、Mac OS Xアプリケーションパッケージには、システムライブラリディレクトリへのシンボリックリンクが含まれていることが非常に多く、それらをクラウドに同期することは望ましくありません（特にOSの異なるバージョン間）。 しかし同時に、シンボリックリンクを使用して追加のディレクトリを同期する機能は非常に魅力的な機会であり、見逃したくはありませんでした。



したがって、シンボリックリンクを同期するための特別なポリシーが導入されました。これにより、カーネルは、シンボリックリンクが指すオブジェクトの場所に応じて、シンボリックリンクごとに特定の同期オプションを選択できます。



３ 。 クラウドファイルシステムツリーを取得します 。 同期の問題を解決するには、ローカルファイル構造とファイルダイジェストを用意するだけでは不十分です。クラウド内のファイルシステムの現在の状態を取得する必要があります。 同期コアがPROPFINDメソッドを使用して毎回ツリーを走査する必要がある場合、各同期サイクルに不当に長い時間がかかり、チャネルに不要な負荷がかかります。 そのため、Yandex.Diskソフトウェアは特別なAPIを使用します。これにより、ツリーのバージョンによって決定される既知の瞬間から開始して、クラウド内のファイルツリーの現在の状態とその中で発生した変更を取得できます。



4 。 クラウドファイルシステムの変更に関するアラートを受信します 。 リアルタイムのファイル同期には、クラウド内のファイルに発生した変更のタイムリーな通知が必要です。 クライアントによるサーバーの定期的なポーリングを使用することは可能ですが、クライアントの可能な数を見積もると、このアプローチは拡張性が弱く、サービスインフラストラクチャの急速な過負荷につながるという結論に達しました。 短い検索の後、XMPPプロトコルに落ち着きました。 その実装の1つは、長い間Yandexで機能しています。 これは後にYandex.DiskプロジェクトのWebDAVサーバーの作成に従事したチームによって開発されたため、このプロトコルの統合に問題はありませんでした。



同期コアによって処理されるプッシュ通知には、Yandex.Diskクラウド内のファイルまたはフォルダーで直接発生したイベントだけでなく、さまざまなサービスメッセージも含まれます。 たとえば、余分なスペースの問題や、パブリックフォルダー内の他のユーザーのアクション。 これらのイベントを既存のプロトコルに追加しても、XMPPの拡張性により、それほど困難は生じませんでした。これにより、選択が正しいことが再度確認されました。



5 。 同期操作のリストを作成します 。 同期カーネルがローカルとリモートの両方のファイルツリーを自由に使用できるようになったら、同期手順自体を続行できます。 このために、特別なツリー比較アルゴリズムが使用されます。これは、2つの言及されたツリーに加えて、3番目の-最後に同期されたツリーを受け入れます。 アルゴリズムの結果として、ツリーを一般的なビューに表示するためにローカルおよびリモートのファイルとディレクトリで実行する必要がある操作のリストが取得されます。



6 。 同期操作のキューの処理 。 ローカルツリーとリモートツリーの操作のリストの作成は、独立して行われます。 その結果、競合する操作が表示される場合があります。 たとえば、変更されてまだローカルで同期されていないクラウド内のファイルを削除したり、ローカルとクラウド内の両方でファイルを変更したりします。 修正/削除の競合は常にカーネルによって解決され、修正が優先されます。また、二重の修正の競合は、いずれかのファイルバージョンの名前を変更することで解決されます。 したがって、データの安全性を保証し、同期が完了した後、各特定のケースでユーザーにとってより適切な変更を決定する機会をユーザー自身に与えることができます。



同期操作は厳密な順序に従う必要があり、親ディレクトリが作成されるまでファイルを転送できません。 また、新しい場所に移動する必要のあるファイルがまだ存在している間は、ディレクトリを削除できません。 ツリー比較アルゴリズムはすでに目的の順序で操作を作成していますが、エラーが発生した場合は違反する可能性があります。 この状況を防ぐため、各操作には依存関係のリストがあります。実行を開始する前に完了する必要がある一連の操作と、完了するまで開始してはならない一連の操作です。



依存関係に加えて、操作の順序はその優先度の影響を受けます。 たとえば、ファイル転送操作は、ファイルサイズに応じて実行されます（小規模から大規模まで）。



これらのタスクはすべて同時に実行され、並列プロセスの同期の品質とYandex.Disk同期カーネル内のリソースの割り当てに追加の要件が課されます。 Ya.Diskをまだお持ちでない場合は、 こちらから入手してLinuxにインストールできます： repo.yandex.ru/yandex-disk