Ubuntu-fr

Sur cette page, on voit que foldertree.json est utilisé par le folder pane. Tu peux poster ici ce qu'il contient (par curiosité) ? À mon avis c'est pour décrire comment tu veux que tes dossiers apparaissent.

Après pourquoi il se crée, ça je ne sais pas... Mais comme ta question a piqué ma curiosité, je suis allé voir dans les soucres de TB, en plus c'est tout en javascript, très facile à lire/comprendre. Tu peux faire pareil :

1. Télécharge les sources : https://hg.mozilla.org/comm-central/archive/tip.zip
2. Unzip et cd
3. git init
4. git grep -I "folderTree.json"

Et là tu trouves que gFolderTreeView charge ce fichier. gFolderTreeView se trouve dans mail/base/content/folderPane.js.

Dans la function unload de cet objet, on voit qu'il écrit son fichier json (qui doit donc contenir les clés open et colors, tu confirmeras). Puis c'est IOUtils.writeJSON qui s'en occupe. Car pour l'instant, pas de trace des fichiers de backup.

IOUtils est chargé depuis ChromeUtils, et là j'ai pas trouvé où était le code pour le moment. À suivre!

C'est juste pour chercher une string dans les fichiers de manière simple. Avec mes alias je fais "g init; g g something", mais en réalité c'est plus utile dans un repo git, car ça va prendre en compte le .gitignore et donc ça ne va pas chercher dans les fichiers à ignorer. Là vu que c'est du hg tu pourrais faire un "grep -r" ça serait à peu près pareil.

Ce que je te propose c'est d'explorer les sources pour tenter de comprendre pourquoi il crée tous ces fichiers au lieu de nettoyer derrière lui comme un bon programme. Aussi, tu n'as pas posté le contenu du fichier .json comme je te l'ai demandé.

Ok pas de soucis, si ça contient des trucs persos je comprends tout à fait. C'était juste pour avoir une idée du contenu (je n'utilise pas thunderbird (mutt ftw)).

Alors en parcourant des bug reports vieux de 10 ans (1, 2) on apprend :

- c'est bien un crash de l'OS ou du disque dur qui peut corrompre ce fichier, mais ça peut aussi être un truc de backup ou antivirus (bon pas sur ubuntu à priori) qui ouvre le fichier en lecture au même moment
- afin de limiter la possibilité de corruption de ce fichier lorsqu'il est écrit, il écrit d'abord dans un fichier-XXX.js, puis si ça c'est bon il le déplace pour écraser l'ancien (si j'ai bien compris). Ce qui peut expliquer le tas de fichiers qui reste. Même si je ne comprends pas bien cette nécessité : il pourrait toujours écrire sur le même fichier temporaire, et le supprimer une fois qu'il a été copié.

Enfin bref, l'histoire c'est que des utilisateurs avaient des corruptions de ce fichier, et que les devs ont fait de leur mieux pour éviter qu'il ne soit corrompu.