Réparez un magasin Core Data iOS corrompu

Core Data est un framework de graphe d'objets et de persistance, pas une base de données — la base de données, c'est SQLite, et Core Data en maîtrise l'agencement. Ouvrez un magasin Core Data dans n'importe quel explorateur SQLite et vous n'y verrez pas des noms de table conviviaux ; vous verrez un schéma déformé généré par le framework. Chaque entité devient une table nommée Z + le nom de l'entité en majuscules, si bien qu'une entité Person devient la table ZPERSON. Chaque ligne porte trois colonnes système : Z_PK (la clé primaire entière), Z_ENT (quelle entité/sous-classe est la ligne) et Z_OPT (un compteur de version pour le verrouillage optimiste). Vos attributs portent eux aussi un préfixe — firstName devient ZFIRSTNAME — et une relation à-un est stockée comme une colonne de clé étrangère contenant le Z_PK de la ligne de destination.

À côté de vos données se trouvent trois tables de gestion interne. Z_PRIMARYKEY conserve une ligne par entité avec les colonnes Z_ENT, Z_NAME, Z_SUPER et Z_MAX — la clé primaire la plus élevée attribuée jusqu'à présent, que Core Data incrémente pour allouer l'insertion suivante. Z_METADATA conserve Z_VERSION, Z_UUID et Z_PLIST, un blob plist binaire contenant les métadonnées du magasin, dont NSStoreModelVersionHashes et l'UUID du magasin. Z_MODELCACHE met en cache le modèle compilé. Les dates sont stockées comme une valeur REAL en secondes depuis la date de référence de Cocoa, 2001-01-01 00:00:00 UTC — et non l'époque Unix — de sorte qu'un horodatage brut de 0 correspond au 1er janvier 2001.

Tout cela réside dans un conteneur SQLite standard : un tableau plat de pages de taille fixe (4096 octets par défaut), les 16 premiers octets du fichier étant la chaîne magique SQLite format 3\000. La page 1 contient l'en-tête du fichier et le schéma sqlite_master ; chaque table Z est un arbre-b dont les pages internes pointent vers le bas, vers des pages feuilles contenant les enregistrements réels. Cassez un pointeur et SQLite rejette tout le fichier — même si les pages feuilles remplies de lignes sont intactes.

Depuis iOS 7 (et OS X 10.9 Mavericks), Core Data ouvre son magasin en mode WAL — journalisation en écriture anticipée (write-ahead logging) — par défaut. C'est pourquoi un seul magasin correspond en réalité à un maximum de trois fichiers sur le disque : <AppName>.sqlite, <AppName>.sqlite-wal et <AppName>.sqlite-shm. Comprendre la différence détermine si vos données les plus récentes survivent.

Le fichier -wal est le journal d'écriture anticipée. Quand votre app valide une transaction, les pages modifiées sont ajoutées au -wal sous forme de trames plutôt que d'être écrites directement dans le .sqlite principal ; seul un checkpoint périodique les réintègre dans la base de données. La conséquence : si l'app s'est fermée brutalement ou a été forcée à quitter avant un checkpoint, les lignes validées les plus récentes peuvent vivre uniquement dans le -wal. Son agencement est précis — un en-tête de 32 octets (nombre magique 0x377f0682 ou 0x377f0683, une version de format, la taille de page, une séquence de checkpoint, deux valeurs de sel et une somme de contrôle) suivi de trames, chacune avec un en-tête de trame de 24 octets (numéro de page, la taille de la base de données en pages pour une trame de validation ou 0 sinon, les deux sels et deux sommes de contrôle) plus une page de données.

Le fichier -shm est l'index-wal en mémoire partagée (wal-index) : une structure de recherche que SQLite utilise pour localiser rapidement les pages à l'intérieur du -wal. Ce sont des données entièrement dérivées — il ne contient aucune de vos lignes et SQLite le reconstruit automatiquement à partir du -wal. La règle est donc simple : apportez le -wal, ignorez le -shm. Déposez d'abord le .sqlite, puis ajoutez le -wal dans l'emplacement annexe facultatif : ses trames validées sont superposées avant l'analyse, de sorte que la récupération reflète la dernière transaction validée plutôt que le dernier checkpoint. Copier uniquement le .sqlite depuis un appareil et laisser le -wal derrière soi est la manière classique de perdre des données récentes en silence — un piège aussi bien pour la récupération après un plantage que pour l'extraction forensique.

Au niveau de SQLite, le magasin échoue avec l'un de deux codes de résultat. SQLITE_CORRUPT (code 11) affiche "database disk image is malformed" : le moteur a suivi un pointeur et a trouvé quelque chose qui n'est pas une page d'arbre-b valide — une page mise à zéro, un décalage de cellule incorrect, un nombre de pages qui ne concorde pas avec la longueur du fichier. SQLITE_NOTADB (code 26) affiche "file is not a database" : les 16 octets magiques de l'en-tête sont incorrects, ce qui signifie soit que les octets d'en-tête ont été endommagés (les pages situées derrière sont souvent intactes), soit que le fichier est réellement autre chose ou qu'il est chiffré. Core Data l'enveloppe et présente NSCocoaErrorDomain code 259 (NSFileReadCorruptFileError) — "The file couldn't be opened because it isn't in the correct format." — tandis que le code SQLite brut reste à l'intérieur du userInfo de l'erreur, sous la clé NSSQLiteErrorDomain, de sorte qu'une ligne de journal indiquant NSSQLiteErrorDomain=11 est votre confirmation qu'il s'agit d'une corruption au niveau de la page, et non d'une incompatibilité de version de schéma.

La récupération n'essaie pas de réparer le fichier cassé sur place. Elle lit tout ce qui reste décodable et l'écrit dans une base de données neuve — la même stratégie que la commande .recover de SQLite elle-même. Elle parcourt l'arbre-b de chaque table Z et décode les enregistrements des feuilles ; pour les pages que la chaîne de pointeurs n'atteint plus, elle se rabat sur un balayage de pages brutes, capturant les enregistrements auto-descriptifs directement dans le fichier. Les lignes qui ne peuvent pas être rattachées à une table connue atterrissent dans une table lost_and_found au lieu d'être jetées, et les valeurs Z_MAX de Z_PRIMARYKEY sont reconstruites à partir des lignes récupérées afin que l'app puisse continuer à insérer sans collisions de clé primaire. Comme le balayage lit aussi les pages de la liste libre (freelist) et non compactées, les lignes que votre app avait supprimées auparavant peuvent réapparaître — utile, mais bon à savoir.

Une limite honnête est propre à Core Data. Quand un attribut binaire (une photo, un PDF, de l'audio) a l'option "Allows External Storage" cochée, Core Data décide valeur par valeur s'il intègre les octets dans la ligne ou les écrit comme un fichier séparé lorsqu'ils dépassent environ 100 Ko. Ces blobs externes sont stockés dans un répertoire de support caché à côté du magasin — .<storename>_SUPPORT/_EXTERNAL_DATA/ — avec des noms de fichier UUID, et la ligne de la base de données ne conserve qu'une référence vers ce fichier, et non les octets.

Ainsi, récupérer le .sqlite seul renvoie chaque attribut scalaire et chaque blob intégré, mais pour les données stockées en externe, il renvoie la référence, pas l'image. Si vous avez en plus le dossier _EXTERNAL_DATA du même conteneur d'app, ces fichiers se réapparient par nom ; si ce répertoire a disparu, aucune récupération de base de données ne peut reconstruire des octets qui n'ont jamais été à l'intérieur de la base de données. Et comme un magasin Core Data peut contenir tout l'état privé d'une app — chaque note, message, donnée de santé ou compte qu'un utilisateur a un jour enregistré — tout ceci s'exécute dans votre navigateur : le fichier est lu depuis le disque, reconstruit dans l'onglet, et vous pouvez vérifier dans l'onglet Réseau qu'aucun octet ne quitte votre machine.