Réparer un places.sqlite de Firefox corrompu (marque-pages et historique)

Tout le système de marque-pages et d'historique de Firefox réside dans un seul fichier. moz_places conserve une ligne par URL que vous avez visitée ou mise en marque-page : son url, son title, rev_host (l'hôte inversé, pour regrouper rapidement les domaines), visit_count, last_visit_date, un guid, un url_hash et frecency, un score propre à Firefox qui combine fréquence et récence (frequency + recency) et classe les suggestions de la barre d'adresse. Chaque visite concrète est une ligne de moz_historyvisits, dont le place_id renvoie à moz_places.id. Votre arbre de marque-pages, c'est moz_bookmarks : chaque ligne porte un parent, une position, un title, un guid et une clé étrangère fk vers moz_places. L'arbre est suspendu à des dossiers racines fixes dotés de guids permanents de 12 caractères : root________, menu________ (Menu des marque-pages), toolbar_____ (Barre des marque-pages), unfiled_____ (Autres marque-pages), mobile______ et tags________. Autour d'eux se trouvent moz_origins, moz_keywords, les tables d'annotations moz_anno_attributes/moz_annos/moz_items_annos, moz_inputhistory et moz_meta. Les favicons ne sont pas ici : depuis Firefox 55, ils résident dans un favicons.sqlite distinct, dans le même profil.

Physiquement, le fichier est un tableau plat de pages de taille fixe. Firefox crée places.sqlite avec une taille de page de 32 KiB (PRAGMA page_size = 32768, compilée en tant que SQLITE_DEFAULT_PAGE_SIZE) — huit fois la valeur par défaut de 4 KiB de SQLite — et l'exécute en mode WAL, si bien que vous verrez deux fichiers frères à côté : places.sqlite-wal (le journal d'écriture anticipée) et places.sqlite-shm (un index en mémoire partagée). La page 1 contient l'en-tête et le schéma ; chaque table et index est un arbre-B dont les pages internes pointent vers le bas, vers les pages feuilles qui contiennent vos lignes.

Ces pointeurs sont le point faible. Une écriture interrompue, un plantage en plein checkpoint, un disque plein, un secteur défectueux ou un octet retourné dans une seule page interne de 32 KiB suffisent : SQLite suit le pointeur, tombe sur quelque chose qui n'est pas une page valide et déclare toute l'image corrompue — alors que vos lignes reposent intactes dans les pages feuilles qu'il n'a jamais atteintes. C'est la carte qui s'est cassée, pas les données.

Firefox vérifie places.sqlite au démarrage. Si l'ouverture bute sur SQLITE_CORRUPT ou qu'un contrôle d'intégrité échoue, le service Places considère le fichier comme inutilisable et fait quelque chose de radical sans rien demander : il renomme places.sqlite en places.sqlite.corrupt dans le dossier du profil, crée un places.sqlite tout neuf et vide, puis restaure vos marque-pages depuis le fichier le plus récent du dossier bookmarkbackups — bookmarks-YYYY-MM-DD_<count>_<hash>.jsonlz4, compressé avec le mozLz4 de Mozilla (un magic de 8 octets mozLz40\0, puis une taille décompressée de 4 octets en little-endian, puis un bloc LZ4 — ce n'est pas du LZ4 standard, si bien que les outils ordinaires ne l'ouvrent pas).

Voici le piège qui pousse les gens à chercher une solution : seuls les marque-pages sont sauvegardés de cette façon. L'historique, les scores de frecency, les mots-clés et l'historique de saisie ne sont jamais écrits dans ces fichiers .jsonlz4, si bien qu'une réinitialisation reconstruit discrètement votre arbre de marque-pages et jette tout le reste. Vos marque-pages reviennent avec bonne allure ; des mois ou des années d'historique disparaissent tout simplement de la base de données active.

Les chaînes d'erreur que vous verrez réellement, et ce qu'elles signifient : database disk image is malformed correspond à SQLITE_CORRUPT (code de résultat 11) — une page endommagée, un décalage de cellule incorrect, ou un nombre de pages qui ne concorde pas avec la taille du fichier. file is not a database correspond à SQLITE_NOTADB (code 26) : le magic de 16 octets SQLite format 3\000 de l'en-tête est endommagé, même si les pages derrière lui sont souvent intactes. Et The bookmarks and history system will not be functional because one of Firefox's files is in use by another application est une tout autre bête : c'est un verrou (SQLITE_BUSY), généralement un second processus Firefox ou un antivirus qui retient le fichier, et non une corruption. Comme le renommage se produit automatiquement, le temps que vous remarquiez la barre vide, les bonnes données sont déjà dans places.sqlite.corrupt et le places.sqlite actif est vierge.

Plutôt que de rafistoler le fichier cassé sur place, l'outil lit directement ses pages de 32 KiB, reconstruit le schéma à partir de la page 1, parcourt l'arbre-B de chaque table et se rabat sur un balayage brut des pages, sans pointeurs, pour les lignes que les pointeurs cassés ne peuvent plus atteindre — la même stratégie que la commande .recover de SQLite elle-même. Les enregistrements qui ne peuvent pas être rattachés à une table connue sont placés dans une table lost_and_found au lieu d'être écartés, de sorte qu'une ligne abîmée de moz_places ou moz_bookmarks est conservée plutôt que perdue. Si vous avez encore le fichier frère places.sqlite-wal, ajoutez-le dans l'emplacement optionnel : en mode WAL, les visites et les marque-pages les plus récents peuvent ne vivre que dans ce journal jusqu'au checkpoint, et ses frames validées sont superposées avant le balayage. Le résultat est un places.sqlite neuf et ouvrable que vous téléchargez — recopiez-le dans le profil avec Firefox fermé, ou ouvrez-le en lecture seule pour exporter marque-pages et historique.

Fournissez le fichier places.sqlite.corrupt si Firefox a déjà réinitialisé votre profil : c'est là que se trouve encore votre historique. Pour le localiser, ouvrez about:profiles et cliquez sur « Ouvrir le dossier » (dossier racine) du profil en cours d'utilisation, ou allez directement dans %APPDATA%\Mozilla\Firefox\Profiles\<nom> sous Windows, ~/Library/Application Support/Firefox/Profiles/<nom> sous macOS, ou ~/.mozilla/firefox/<nom> sous Linux. Copiez le fichier ailleurs avec Firefox entièrement fermé, pour que rien ne le verrouille.

Pourquoi cela ne doit pas être téléversé : places.sqlite est, littéralement, un journal complet de chaque page que vous avez visitée. C'est le fichier que vous voudriez le moins voir copié sur le serveur d'une entreprise de réparation « juste pour le réparer », sous des conditions de conservation que vous n'avez jamais lues. Ici, il est lu depuis votre disque et reconstruit dans l'onglet du navigateur — vous pouvez ouvrir le panneau Réseau et confirmer que 0 octet de la base de données ne quitte jamais votre machine.