mirror of
https://github.com/vrtmrz/obsidian-livesync.git
synced 2026-11-06 16:28:18 +00:00
Chihiro WATANABE
5ffa3b76ed
- Overhaul Japanese translation catalogue and synchronize with current documentation - Localise pending UI labels across dialogues, panels, and settings - Add Japanese translation mapping for provisional LiveSync messages - Update and refine all Japanese documentation files - Strip weak ETag prefix in ObsHttpHandler for object storage compatibility
92 lines
12 KiB
Markdown
92 lines
12 KiB
Markdown
# ファストセットアップ (Fast Setup / Simple Fetch)
|
||
|
||
ファストセットアップ（Simple Fetch）は、新規または空の2台目以降のデバイスに初期複製する際の推奨フローです。復旧にも使えますが、取得時の選択によってローカルファイルが置き換わることがあります。すでに作業がある Vault で処理方法を選ぶ前に、価値のあるローカルデータとリモートデータを保全してください。正本を特定する方法は[復旧とフラグファイル](../recovery.md#first-choose-the-authoritative-copy)を参照してください。
|
||
|
||
従来のセットアップウィザードにおける複数の詳細なステップを踏むことなく、同期の基本方針を選択するだけで、データベースのダウンロードとローカルファイルのスキャン・反映を一連のプロセスとして自動的に実行します。取得経路は、選択したリモートによって異なります。
|
||
|
||
---
|
||
|
||
## 仕組み
|
||
|
||
2台目以降のデバイスで **セットアップ URI** をインポートした場合や、手動でデータの再取得（Vault ルートに `redflag3.md` / `flag_fetch.md` を配置する等）が予約された場合、プラグインはリモートデータベースからのデータ取得スケジュールを設定します。
|
||
|
||
その後の起動時、プラグインはデータ取得予約モードで立ち上がり、**「Data retrieval scheduled（データ取得のスケジュール）」** という簡略化されたダイアログを表示します。
|
||
|
||
---
|
||
|
||
## 技術的な特徴
|
||
|
||
ファストセットアップでは、取得と反映に関して次の動作を行います。
|
||
|
||
1. **CouchDB 向けのストリームベースの Fast Fetch**
|
||
- ストリームベースの Fast Fetch は CouchDB 専用です。リモートのメタデータを段階的に取得します。オブジェクトストレージと P2P は、それぞれ独自の取得経路を使用します。
|
||
2. **ストレージ反映の遅延による不要な警告の抑制**
|
||
- 取得中にローカルファイルへの反映を遅延させることで、リモートデータの取得中に発生する一時的な同期警告を抑制します。
|
||
3. **更新日時を比較してファイル全体を選択**
|
||
- **更新日時を比較して新しい方を採用** は更新日時を比較し、ファイル全体として新しい方のバージョンを選択します。ファイルの内容をマージする処理ではありません。作業中の Vault にこの方法を使う前に、価値のあるローカルおよびリモートの編集内容を保全し、[復旧とフラグファイル](../recovery.md#first-choose-the-authoritative-copy)を確認してください。
|
||
|
||
---
|
||
|
||
## 設定手順
|
||
|
||
### ステップ 1: データの反映方法の選択
|
||
取得したリモートデータを、既存のローカルファイルとどのように統合するかを選択します。
|
||
|
||
1. **更新日時を比較して新しい方を採用（newer-wins）**
|
||
- ファイルの更新日時を比較し、ファイル全体として新しい方のバージョンを採用します。両方のバージョンの編集内容を統合するものではありません。
|
||
- **推奨されるケース:** 両方のバージョンを保全した上で、更新日時に基づいてどちらかを意図的に選択したい場合。
|
||
- 作業中の Vault にこの方法を使う前に、価値のあるローカルおよびリモートの編集内容を保全し、[復旧とフラグファイル](../recovery.md#first-choose-the-authoritative-copy)を確認してください。
|
||
2. **すべてリモートのファイルで上書き（remote-wins）**
|
||
- リモートデータベースの内容を正（Source of Truth）として扱います。
|
||
- **推奨されるケース:** 新しい2台目以降のデバイスを、空の Vault でセットアップする場合。
|
||
- *警告: ローカルにあるすべてのファイルがリモートの内容で上書きされます。重要なデータがある場合は、事前にバックアップを取得してください。*
|
||
3. **詳細フローを使用（legacy）**
|
||
- 従来の詳細なセットアップウィザードダイアログに戻ります。
|
||
- **推奨されるケース:** データベースの構成オプションをステップバイステップで細かく制御・確認したい場合。
|
||
|
||
### ステップ 2: 競合および削除ルールの構成
|
||
ステップ 1 での選択内容に応じて、ローカルとリモートの不一致をどう処理するかを設定します。
|
||
|
||
#### 「更新日時を比較して新しい方を採用」を選択した場合:
|
||
- **リモートで削除されている場合はローカルファイルを削除**
|
||
- 他のデバイスで削除済みのファイルをローカルからも削除し、ローカル Vault を整理して他のデバイスと揃った状態に保ちます。
|
||
- **リモートで削除されていてもローカルファイルを保持**
|
||
- 他のデバイスで削除されたファイルであっても、ローカルファイルを維持し、リモートデータベースに再度アップロードします。
|
||
|
||
#### 「すべてリモートのファイルで上書き」を選択した場合:
|
||
- **リモートに存在しない場合はローカルファイルを削除**
|
||
- リモートに存在しないローカル専用ファイルを削除し、ローカルの Vault をリモートデータベースと完全に一致させます。
|
||
- **リモートに存在しなくてもローカルファイルを保持**
|
||
- リモートに存在しないローカルファイルをそのまま残します。ただし、同期後に重複ファイルが発生する可能性があるため、その場合は手動でクリーンアップを行ってください。
|
||
|
||
### ステップ 3: 自動同期の実行
|
||
選択を確定すると、以下の処理が順次実行されます。
|
||
1. リモートデータベースの高速ダウンロードを実行します (`fetchLocalDBFast`)。
|
||
2. ローカルファイルへの変更反映のため、フォアグラウンドでフルスキャン (`synchroniseAllFilesBetweenDBandStorage`) を自動的に実行します。
|
||
3. 処理が完了すると、プラグインは通常の動作状態へ復帰します。
|
||
|
||
### ファストセットアップが中断した場合
|
||
|
||
ファストセットアップは、ドキュメントを保存しながら最後に正常に保存されたリモートの位置を記録します。一時的な接続の中断が発生した場合、その位置から自動的に再試行されます。キャプチャされたリモートの状態が正常にすべて保存された後にのみ、完了が報告されます。
|
||
|
||
データの復号、リモートレスポンスの読み取り、またはローカルデータベースへの書き込み中のエラーによって処理が停止した場合、LiveSync は Vault スキャンを実行せず、再構築されたローカルデータベースの確定も行いません。保存された位置と取得フラグはそのまま保持されます。保存された有効な選択肢は、再起動時に確認ダイアログで再び利用できます。部分的に再構築されたデータベースが Vault に適用されたり、新しいローカル変更と混ざったりしないよう、ファイル監視とデータベースの反映も一時停止されたままになります。
|
||
|
||
**ログを表示** で最初のエラー内容を確認し、原因を修正してから Obsidian を再起動して、保持された状態から再試行してください。処理を続行する意思がある間は、取得フラグを削除したり、手動で Scram スイッチを再開したりしないでください。再起動後も同じエラーが解消しない場合は、LiveSync を一時停止したままデータを保護し、[レポートを収集](../troubleshooting.md#collect-a-report) してください。
|
||
|
||
|
||
## 取得フラグに記憶される選択肢
|
||
|
||
ファストセットアップは、選択肢を `flag_fetch.md`（または取得フラグがそれだけの場合は `redflag3.md`）内の `json` コードブロックに保存します。このファイルは通常の Markdown であり、Obsidian 内で開いて編集できます。選択肢が更新されても、状態ブロックの外側にある説明文は保持されます。フラグファイル全体は一時的なものであり、処理が完了またはキャンセルされたときに削除されます。
|
||
|
||
中断後に再起動すると、現在のリモートと保存された選択肢が表示されます。それらの選択肢で続行するか、選び直すか、あるいは予約された取得をキャンセルできます。前回の取得が完了したもののフラグを削除できなかった場合も含め、保存された選択肢が確認なしに適用されることはありません。
|
||
|
||
新しい参加（Join）を開始するか、別の取得を予約すると、`flag_fetch.md` は空のフラグに置き換えられ、新しい選択肢が求められます。両方のファイル名が存在する場合は、空の場合も含めて `flag_fetch.md` が優先され、完了時に両方のエイリアスが削除されます。
|
||
|
||
生成されるブロックには `type: "livesync-fast-setup"`、`version: 1`、および2つの安定した英語の選択値（`stage1` と `stage2`）が含まれます。接続の認証情報は保存されません。既存の選択肢の認識可能な組み合わせのみが受け入れられます。確認を行うと、P2P 接続設定を変更した後であっても、現在選択されているリモートに選択肢が適用されます。
|
||
|
||
空のフラグがある場合は、通常の選択ダイアログが起動します。空ではないフラグに対応する有効な選択肢が含まれていない場合、プラグインは新しい選択肢を指定して続行するかどうかを確認します。これには不正な形式の JSON、未対応のバージョン、重複した状態ブロック、不完全な Markdown のコードフェンスなどが含まれます。続行を選択した場合、ファイル内容は変更されず、今回の試行にのみ新しい選択肢が使用されます。再起動すると再度確認が行われます。プラグインが Markdown を修復したり、代替ブロックを追加したりすることはありません。取得を完了またはキャンセルすると、説明文を含めフラグファイル全体が削除されます。
|
||
|
||
ストレージの読み取りまたは書き込みに失敗した場合は処理が停止し、空のフラグとしては扱われません。処理の最後にフラグの削除に失敗した場合、その問題が解決するまでファイル監視とデータベースの反映は一時停止されたままになります。フラグが残っている場合、再起動時に再度確認が求められます。
|
||
|
||
以前のバージョンでは、選択肢をデバイスのローカルストレージに個別に保存していました。それらの値は完了した取得の後にも残存している可能性があるため、再利用されなくなりました。中断された処理の実行中に更新した場合は、もう一度選択肢を確認してください。この変更自体によってダウンロード済みのデータや Fast Fetch（ファストフェッチ）のチェックポイントが削除されることはありません。
|