En informatique, quelque soit le système avec lequel on opère, il arrive inévitablement qu'un certain nombres de bugs se produisent, même en l'absence de défaut logiciel.

Quand on travaille sur une machine qui contient plus d'un million de fichiers, la corruption de quelques-uns d'entre eux à plus ou moins brève échéance est quasi inévitable . Cela engendre des bugs. Des choses qui marchaient depuis des mois commencent à dysfonctionner, et on s'interroge, qu'est-ce que j'ai fait pour que ça arrive ? Est-ce à cause d'un logiciel que j'ai installé récemment, d'un paramètre que j'ai changé quelque part ? Est-ce à cause d'un virus, d'un cheval de Troie que j'ai laissé imprudemment pénétrer mon système ?

Souvent on n'a rien fait du tout, c'est juste un effet du temps. Prenons l'exemple de l'index de Spotlight. Spotlight est le moteur de recherche intégré au Finder, celui qui est activé quand on clique sur la loupe en haut à droite de l'écran et qu'on saisit une recherche. Derrière Spotlight il y a un dossier invisible qui s'appelle .Spotlight et qui est à la racine du disque dur. Ce dossier est actualisé en permanence, et grossit au fil du temps. À chaque fois qu'on crée, qu'on supprime ou qu'on modifie un ficher, il est mis à jour. Et il arrive un moment où il a tellement grossi qu'il devient incapable de faire son travail.

La solution alors consiste à réinitialiser cet index, pour qu'il reparte à zéro et recommence à indexer l'intégralité du disque comme après la toute première installation du système.

Les sources de bug sont infinies. Quand on est confronté à un problème, il y a Google bien sûr, et les forums techniques. Mais quand on a tout essayé et qu'on n'a toujours pas de réponse, qu'on semble seul au monde à avoir le problème, que peut-on faire ?

La mauvaise solution, c'est de réinstaller tout le système. Bien sûr le bug disparaît... au début. Puis les gens importent les données de leur ancien système, retrouvent leurs habitudes, et quelques semaines ou mois après avoir réinstallé le système, le bug revient ! Évidemment, puisqu'ils n'ont pas cherché à comprendre comment le bug est apparu.

La bonne démarche par contre, c'est de chercher l'origine du bug, d'en comprendre les causes, d'identifier les éléments corrompus. Ce n'est pas facile, mais si l'on trouve on aura appris quelque chose et on saura quoi faire la prochaine fois. 

Dans cette optique, on peut par exemple créer un autre utilisateur de type admin, qui aura donc les mêmes droits que la session principale. La plupart des applications étant communes à tous les utilisateurs, on pourra généralement tester ce qui pose problème sur cette session de test.

On prendra soin de fermer la session principale avant de lancer la session de test, pour se retrouver dans des conditions à peu près équivalentes.

Si le bug se produit aussi, on peut en conclure qu'il se niche en dehors du dossier Utilisateur. Dans l'Application qui bogue par exemple, ou dans le Système lui-même.

Si par contre il ne se produit pas sur la session de test, cela devient intéressant, car on va pouvoir comparer ce qui se passe sur les deux sessions. Pour cela on va faire appel au logiciel FSMonitor, qui liste sous forme de graphique tous les éléments qui sont impactés par les processus qui se déroulent à un instant t.

Je prends un exemple vécu : j'avais sur le logiciel Notes d'Apple un problème de synchronisation avec iCloud, quand je lançais Notes la roue grise à côté d'iCloud ne s'arrêtait jamais de tourner, et les Notes saisies sur le Mac n'étaient plus remontées vers iCloud.

Le problème ne se posant pas dans ma session de test, j'ai donc lancé FSMonitor sur ma session principale, j'ai ouvert le logiciel Notes, j'ai laissé tourner une dizaine de secondes et j'ai arrêté l'enregistrement des actions. En filtrant sur "notes" j'ai obtenu ceci : 

J'ai ensuite fait la même chose sur ma session de test et j'ai obtenu cela :

En comparant les deux graphiques, une chose saute aux yeux. Dans la partie basse des graphiques, le chemin /private/var/folders tient sur une seule ligne dans la session de test, avec une branche T unique, alors qu'elle se subdivise en deux branches dans la session où le bug se produit, avec une branche C qui contient un dossier com.apple.Notes.

C'est la seule différence entre les deux deux graphes. Cela m'a mis immédiatement sur la piste : j'ai jeté à la corbeille ce dossier com.apple.Notes, sans la vider (on ne sait jamais), j'ai lancé Notes et... le bug avait disparu ! J'avais trouvé le fautif. Sans doute y avait-il là-dedans une base de données qui était dans un sale état. En la mettant à la corbeille elle a été recréée à neuf par l'application Notes : problème réglé.

Si donc un jour vous êtes confronté à un bug récalcitrant, pensez à cette méthode d'isolation des problèmes, avant de tout réinstaller.