Skip to content

システムアーキテクチャ設計 ​

Lertaro は、ミリ秒単位の検索とデスクトップ統合を実現しつつ、システム安定性とセキュリティを確保するために、疎結合なマルチプロセス分離モデルを採用しています。

Runtime processes and communication
lff.exeOptional command-line client
Per-user, per-session search pipe
Desktop application
Lertaro.App.exeStandard user · WPF

Search windows, settings, previews and plugin search providers

App ↔ ServiceLertaroPipeSearch requests ↔ results
Indexing serviceLertaro.Service.exe --serviceLocalSystem · Windows service

NTFS / ReFS metadata, FAT / exFAT watchers and network directory caches

App ↔ HookLertaro_Hook_Events / CmdsWindow events ↔ commands
Hooks and window adaptersLertaro.Service.exe --hookInteractive user session

Keyboard / mouse hooks, active paths and file-dialog integration

Service launches the Hook for the signed-in session. Hook elevation is available only for administrator accounts.

Shared libraries — loaded into processes, not separate services

Lertaro.CoreIndex snapshots, fuzzy matching and IPC contracts

Lertaro.PluginSdkSearch / UI in App · adapters in Hook · aliases / translations also in Service

1. 3 プロセス分離モデル ​

単一コンポーネントの不具合によるシステム全体のクラッシュを防ぎ、管理者権限の範囲を最小限に抑えるため、Lertaro の実行環境は 3 つのプロセスに明確に分離されています。

1. バックグラウンドインデックスサービス(Lertaro.Service.exe) ​

  • 実行権限:Windows システムの LocalSystem 権限で常駐する Windows サービス。
  • 担当範囲:全ドライブのインデックス作成と変更監視を担当。NTFS / ReFS ドライブの USN 変更ジャーナルおよび $MFT を直接読み取り、FAT32 / exFAT の変更イベントを監視し、SMB / NAS 共有を定期的にキャッシュします。
  • セキュリティと性能:SYSTEM 権限で実行されるため UAC プロンプトなしで低レベルのボリュームメタデータに直接アクセスでき、高速な名前付きパイプを通じて結果をユーザープロセスの App に返します。UI プロセスに不要な管理者権限を持たせない安全な設計です。

2. ユーザー UI メインプロセス(Lertaro.App) ​

  • 実行権限:標準ユーザー権限で動作するセッション分離された WPF デスクトップアプリ。
  • 担当範囲:クイック検索ウィンドウ、メイン検索ウィンドウ、設定画面、グローバルホットキー処理、アクションメニュー(Ctrl+O)、QuickLook プレビューを担当。
  • IPC と CLI 共有:双方向の名前付きパイプ LertaroPipe を介してバックグラウンドサービスと通信します(Core.Services.Search.SearchService は App 側のクライアントです)。また、ユーザーごとの名前付きパイプ(AppSearchPipeService)をホストしており、lff コマンドラインツールが App の構築済みメモリテーブルやプラグインを再初期化なしで共有利用できます。

3. キーボードフック・ウィンドウ統合プロセス(Lertaro.Service --hook) ​

  • 実行権限:バックグラウンドサービスによって起動される専用のヘルパープロセス。サインインしているアカウントが実際の管理者である場合にのみ昇格して起動され、それ以外の場合はユーザー自身のトークンで動作します。したがって、後述の回避が使えるのはそうしたマシン上だけになります。
  • 担当範囲:低レベルキーボードフックおよびマウス監視を担当。
  • UIPI の回避と耐障害性:Windows の UIPI(ユーザーインターフェイス特権の分離)により、低権限プロセスから管理者権限で実行中のウィンドウへメッセージを送信することは制限されています。この Hook プロセス上でウィンドウアダプター(IActivePathCollector, IFileDialogAdapter, IInlineSearchAdapter)を実行すれば、Hook が昇格して起動されているときに限り、管理者権限で実行されているエクスプローラー、Total Commander、ファイル ダイアログを読み取り操作できます。また、フック処理がクラッシュしてもメイン App には影響しません。

2. 共通コアライブラリ(Lertaro.Core) ​

Lertaro.Core は、Service、App、Hook の各プロセスから共通して参照される基本ライブラリです。

  • 独自 fzf あいまい一致エンジン(Core/SearchIndex/Fzf/*):fzf アルゴリズムに基づく文字飛び一致、スコアリング、ハイライトマスク計算を実装。
  • 列指向インメモリインデックス(Core/IndexV2/*):メモリマップト列指向スナップショットとインメモリ差分レイヤーにより、数億件のファイルからミリ秒未満で結果を抽出。
  • バイナリ IPC 通信仕様:SearchRequestMessage などの標準バイナリプロトコルにより、プロセス間でゼロコピーに近い高速なシリアライズを実現。
  • 統合ログシステム(Logger):service.log、app.log、hook.log にそれぞれ出力し、設定画面のログビューアーから統合的に閲覧可能。

3. プラグインシステムのアーキテクチャ上の位置づけ ​

すべてのプラグインは Lertaro.PluginSdk をベースに構築され、Lertaro.App 起動時に動的ロードされます。

  • 標準コンポーネント:プラグイン自身のコードは、それをロードしたプロセスと同じプロセス内で実行されます。通常は App ですが、Service もロードする 2 種類のコンポーネントについては次の項を参照してください。プラグイン自体がプロセス境界を越えることはないため、独自のディレクトリ インデックスが必要なプラグインは、ディスクを直接走査するのではなく DirectoryIndexerService を介して処理を依頼します。
  • 選択的な二重ロード:検索ソース、アクション、UI コンポーネントは App プロセス内でのみ動作します。ほかのプロセスにもロードされるのは次の 3 つです。ウィンドウおよびファイル ダイアログ アダプター(IActivePathCollector、IFileDialogAdapter、IInlineSearchAdapter)は、異なる整合レベルのウィンドウを自動化するため Hook プロセスに渡され、IAliasProvider と ITranslationProvider は Service にもロードされます(ServicePluginLoader)。インデクサーがエイリアスの行を構築し、UI に表示されるのと同じ文字起こしと命名を必要とするためです。