Charles-Édouard Coste

Backup corrompu sur un Jolla : Comment récupérer ses contacts

Pour ceux qui auraient un jour un problème de corruption de données sous SailfishOS, voici la solution par laquelle je suis passé pour réussir à sauver les meubles. Attention ! Cet article s'adresse à un public ayant des connaissances en git.

Dans ma famille, nous sommes actuellement cinq à avoir un Jolla comme smartphone. Il fallait bien qu'il y en ai un qui présente des défauts ! Ce fut le cas de celui de ma mère qui présenta des problèmes de corruption de données. Ainsi, quand il refusa de démarrer après une mise à jour foireuse, même la sauvegarde sur la carte micro-SD n'était pas exploitable.

Si ce genre d'incident était arrivé sur un autre OS, je ne suis pas sûr que j'aurais pu y faire quoi que ce soit. Mais dans le cas du Jolla, les développeurs de SailfishOS ont eu la bonne idée d'utiliser git comme système de sauvegarde. Ainsi, un backup n'est rien d'autre qu'un commit sur un dépôt git local et le fichier copié sur la carte mémoire n'est qu'une archive tar du dépôt git.

Ainsi, après avoir extrait le contenu du fichier Backup.tar stocké sur la carte mémoire, j'ai pu obtenir un dossier .git. Mais alors qu'une commande git checkout aurait normalement permis de récupérer l'ensemble des fichiers indexés, je n'ai eu droit qu'à un méchant message d'erreur :

error: object file .git/objects/51/d34da4c175a48ff94cdcc5d91761aab62d9522 is empty error: object file .git/objects/51/d34da4c175a48ff94cdcc5d91761aab62d9522 is empty fatal: loose object 51d34da4c175a48ff94cdcc5d91761aab62d9522 (stored in .git/objects/51/d34da4c175a48ff94cdcc5d91761aab62d9522) is corrupt

J'ai bien cherché la solution sur différents forums et sur stackoverflow. La plupart des commandes telles que git fsck ou git gc me donnaient toujours le même message d'erreur. Cependant, j'ai fini par découvrir deux commandes bien pratiques.

La première est git ls-files. Avec l'argument --stage, elle permet de lister tous les fichiers indexés ainsi que leur sha1 respectif. Ainsi la commande git ls-files --stage m'a donné quelque chose comme ça :

100644 f33d8b0c9842ecef0427090e4091cfeeabb24619 0 .message 100644 00750edc07d6415dcc07ae0351e9397b0222b7ba 0 .vault 100644 a1367e76df44cf8c8aee6a5e7ba7db8575561810 0 Accounts/data/.local/share/system/privileged/Keys/storedkeys.ini 120000 eb9029822db8cd9ed5c2cac16eae5e1f5f056c36 0 Browser/blobs/.cache/org.sailfishos/sailfish-browser/tab-2-thumb.jpg [...] 100644 de927509e521f557e3c4616e4898fcbeb98c0702 0 People/data/all.vcf [...]

Il se trouve que la partie la plus importante était, pour moi, la liste des contacts. Celle-ci se trouve dans People/data/all.vcf. Mais comment récupérer ce fichier ?

Il existe une deuxième commande très pratique : git cat-file qui permet d'obtenir diverses informations sur un fichier indexé. Pour cela, on doit lui fournir le sha1 que nous a fourni la commande git ls-files et un argument précisant ce que l'on souhaite obtenir. L'argument -s permet d'avoir la taille du fichier, -t son type, mais ce qui nous intéresse c'est -p qui permet d'obtenir le contenu du fichier.

Ensuite, une simple redirection de flux permet de récupérer le contenu du fichier si celui-ci ne fait pas partie des fichiers corrompus :

git cat-file -p de927509e521f557e3c4616e4898fcbeb98c0702 > all.vcf

Voilà ! Si vous aussi vous vous retrouvez un jour dans cette situation, j'espère que cet article pourra servir à récupérer les fichiers qui vous tiennent à cœur. Ici, je souhaitais surtout récupérer la liste des contacts, mais vous pouvez récupérer la base de données sqlite des SMS, l'historique de navigation, et bien d'autres choses encore.