Firefox の破損した places.sqlite を修復する（ブックマークと履歴）

Firefox のブックマークと履歴のシステムは、そのすべてが 1 つのファイルの中にあります。moz_places は、あなたがこれまでに訪れた、あるいはブックマークしたすべての URL につき 1 行を保持します — その url、title、rev_host（ドメインをすばやくまとめるために逆順にしたホスト名）、visit_count、last_visit_date、guid、url_hash、そして frecency（frequency（頻度）と recency（新しさ）を組み合わせた Firefox 独自のスコアで、アドレスバーの候補の並び順を決めます）です。実際の 1 回ごとの訪問は moz_historyvisits の 1 行で、その place_id が moz_places.id を指し返します。あなたのブックマークツリーは moz_bookmarks です。各行は parent、position、title、guid、そして moz_places への外部キー fk を持ちます。このツリーは、12 文字の恒久的な guid を持つ固定のルートフォルダーからぶら下がっています — root________、menu________（ブックマークメニュー）、toolbar_____（ブックマークツールバー）、unfiled_____（他のブックマーク）、mobile______、tags________ です。その周りには moz_origins、moz_keywords、注釈テーブルの moz_anno_attributes/moz_annos/moz_items_annos、moz_inputhistory、そして moz_meta があります。ファビコンはここにはありません — Firefox 55 以降、それらは同じプロファイル内の別の favicons.sqlite にあります。

物理的には、このファイルは固定サイズのページが並んだ平坦な配列です。Firefox は places.sqlite を 32 KiB のページサイズ（PRAGMA page_size = 32768、SQLITE_DEFAULT_PAGE_SIZE としてコンパイル時に組み込み）で作ります — SQLite の既定である 4 KiB の 8 倍です — そしてこれを WAL モードで動かすため、その隣に 2 つの兄弟ファイルが見えます。places.sqlite-wal（先行書き込みログ）と places.sqlite-shm（共有メモリのインデックス）です。ページ 1 にはヘッダーとスキーマが入ります。すべてのテーブルとインデックスはB ツリーで、その内部ページは、あなたの行を保持するリーフページへと下向きに指しています。

これらのポインタこそが弱点です。書き込みの中断、チェックポイントの途中でのクラッシュ、ディスクの空き容量切れ、不良セクタ、あるいは 32 KiB の内部ページ 1 つで起きた 1 ビットの反転 — これだけで十分です。SQLite はポインタをたどり、有効なページではない何かに行き当たり、イメージ全体を malformed（不正な形式）と宣言します — 一方、あなたの行は、そこにたどり着けなかったリーフページの中に手つかずで残っています。壊れたのは地図であって、データではありません。

Firefox は起動時に places.sqlite をチェックします。開こうとして SQLITE_CORRUPT にぶつかったり、整合性チェックに失敗したりすると、Places サービスはそのファイルを使えないものとみなし、何も尋ねずに思い切ったことをします。プロファイルフォルダー内で places.sqlite を places.sqlite.corrupt にリネームし、まっさらな空の places.sqlite を作り、それから bookmarkbackups フォルダーの中で日付が最も新しいファイルからブックマークを復元します — bookmarks-YYYY-MM-DD_<count>_<hash>.jsonlz4 で、Mozilla の mozLz4 で圧縮されています（8 バイトの mozLz40\0 というマジックナンバー、続いて 4 バイトのリトルエンディアンの展開後サイズ、そして LZ4 ブロック — 素の LZ4 ではないので、普通のツールでは開けません）。

ここに、人々が解決策を探し回るきっかけとなる落とし穴があります。このやり方でバックアップされるのはブックマークだけです。履歴、frecency のスコア、キーワード、入力履歴は、それらの .jsonlz4 ファイルには決して書き込まれません。そのためリセットは、あなたのブックマークツリーを何も言わずに作り直し、それ以外のすべてを捨てます。ブックマークは何事もなかったかのように戻ってきますが、何か月分、何年分もの履歴は、稼働中のデータベースからただ消えてしまいます。

あなたが実際に目にするエラー文字列と、その意味は次のとおりです。database disk image is malformed（データベースのディスクイメージが不正な形式です）は SQLITE_CORRUPT（結果コード 11）です — 損傷したページ、誤ったセルオフセット、あるいはファイルサイズと食い違うページ数です。file is not a database（ファイルがデータベースではありません）は SQLITE_NOTADB（コード 26）です。16 バイトのヘッダーのマジックナンバー SQLite format 3\000 が壊れているものの、その背後のページはたいてい無事です。そして The bookmarks and history system will not be functional because one of Firefox's files is in use by another application（Firefox のファイルの 1 つが別のアプリケーションに使われているため、ブックマークと履歴のシステムは機能しません）はまったく別物です — これはロック（SQLITE_BUSY）で、たいていは 2 つ目の Firefox プロセスかアンチウイルスがファイルをつかんでいるためであり、破損ではありません。リネームは自動的に起こるので、空になったツールバーに気づくころには、良いデータはすでに places.sqlite.corrupt の中にあり、稼働中の places.sqlite は空になっています。

壊れたファイルをその場でパッチするのではなく、ツールは 32 KiB のページを直接読み、ページ 1 からスキーマを再構築し、各テーブルの B ツリーをたどり、壊れたポインタではもう到達できなくなった行については、ポインタを使わない生ページスキャン（raw page scan）にフォールバックします — SQLite 自身の .recover コマンドとまったく同じ戦略です。既知のテーブルに割り当てられないレコードは、捨てるのではなく lost_and_found テーブルに置かれます。そのため、崩れた moz_places や moz_bookmarks の行も、失われるのではなく保存されます。places.sqlite-wal の兄弟ファイルがまだ手元にあれば、オプションのスロットに追加してください。WAL モードでは、最新の訪問やブックマークは、チェックポイントされるまでそのログの中だけに存在することがあり、そのコミット済みフレームがスキャン前に重ね合わされます。出力は、開くことのできる新しい places.sqlite で、ダウンロードできます — Firefox を閉じた状態でプロファイルにコピーして戻すか、読み取り専用で開いてブックマークと履歴をエクスポートしてください。

places.sqlite.corrupt ファイルを渡すのは、Firefox がすでにあなたのプロファイルをリセットしてしまっている場合です — あなたの履歴がまだ残っているのはそこです。見つけるには、about:profiles を開き、使用中のプロファイルの「Open Directory」（ルートディレクトリを開く）をクリックするか、Windows なら %APPDATA%\Mozilla\Firefox\Profiles\<name>、macOS なら ~/Library/Application Support/Firefox/Profiles/<name>、Linux なら ~/.mozilla/firefox/<name> に直接行ってください。何もファイルをロックしないよう、Firefox を完全に閉じた状態でファイルを外にコピーしてください。

なぜこれをアップロードしてはならないのか。places.sqlite は、文字どおり、あなたがこれまでに訪れたすべてのページの完全な記録です。あなたが決して読まなかった保存条件のもとで、「ただ直すため」に修復業者のサーバーへコピーされることを最も避けたい、まさにその 1 つのファイルです。ここでは、それはあなたのディスクから読み込まれ、ブラウザのタブ内で再構築されます — Network パネルを開けば、このデータベースの 0 バイトしかあなたのマシンから出ていないことを確認できます。