~/Library/Caches : le dossier unique derrière la moitié de ce blog

Si vous avez lu plus d’un article sur ce blog, vous avez remarqué un motif : DerivedData, caches de navigateurs, caches d’applications Electron, CocoaPods, index JetBrains — une part énorme d’entre eux vivent quelque part sous un seul et même répertoire. Ça vaut la peine de regarder ce répertoire directement, une fois, plutôt qu’application par application.

open ~/Library/Caches

Le Finder masque ~/Library par défaut — maintenez Option en cliquant sur le menu Aller du Finder pour le révéler, ou utilisez la commande open ci-dessus, qui contourne entièrement le réglage des dossiers masqués.

Pourquoi ce dossier existe et pourquoi il est sûr par conception

~/Library/Caches est l’emplacement désigné par Apple lui-même exactement pour cet usage — des données que n’importe quelle application peut régénérer ou retélécharger, que le système d’exploitation est explicitement autorisé à purger sous pression de l’espace disque. Ce n’est pas une convention inventée par des développeurs ; c’est une partie documentée de l’organisation du système de fichiers d’Apple, et toute application Mac bien conçue est censée l’utiliser pour tout ce qui n’est pas essentiel.

Ce seul fait est ce qui rend ce dossier exceptionnellement sûr à vider en bloc, comparé à presque n’importe où ailleurs sur votre disque : par la conception même d’Apple, rien ici n’est censé être la seule copie de quoi que ce soit d’important. Les exceptions pratiques — une poignée d’applications qui détournent le dossier Caches pour des données qui ne sont pas vraiment jetables — sont assez rares pour valoir la peine d’être nommées précisément, ce que cet article fait plus bas.

Le lire directement, classé par taille

du -sh ~/Library/Caches/* 2>/dev/null | sort -hr | head -30

Sur presque n’importe quel Mac utilisé depuis plus d’un an, cette seule commande fait remonter exactement les mêmes noms couverts dans les autres guides de ce blog : com.apple.Safari, Google/Chrome, org.swift.swiftpm, Homebrew, CocoaPods, pip, JetBrains, plus des dizaines d’entrées plus petites provenant d’applications que vous ne penseriez jamais à vérifier individuellement.

Les noms de dossiers sont presque toujours des identifiants de paquet en DNS inversé (com.company.AppName) ou de simples noms de paquets (pip, Homebrew) — si vous en voyez un que vous ne reconnaissez pas, mdfind "kMDItemCFBundleIdentifier == '<the-name>'" vous dira généralement à quelle application installée il appartient.

L’approche « tout supprimer en bloc, sans risque »

Pour la plupart des gens, la plupart du temps, c’est vraiment sans problème :

rm -rf ~/Library/Caches/*

Chaque application bien conçue reconstruit ce dont elle a besoin depuis ce dossier la prochaine fois qu’elle se lance — c’est toute la raison d’être de ce répertoire. Le coût visible est la somme de chaque coût individuel couvert ailleurs sur ce blog : les navigateurs retéléchargent leurs ressources, les gestionnaires de paquets retéléchargent à la prochaine installation, l’index d’Xcode se reconstruit, et ainsi de suite — rien ne casse, plusieurs choses sont brièvement plus lentes.

Les exceptions à connaître par leur nom

Un petit nombre d’applications utilisent leur sous-dossier Caches pour des données plus coûteuses à perdre que le mot « cache » ne le laisse penser, couvertes plus en détail dans leurs propres articles :

• L’IndexedDB de Slack peut contenir des brouillons de messages non envoyés — voir le guide Slack et Discord.
• L’IndexedDB de n’importe quelle application utilisé comme stockage local-first (certaines PWA, certaines applications de prise de notes) — voir le guide des caches de navigateur.
• Le cache de Docker vit techniquement entièrement en dehors de ce dossier — il se trouve à l’intérieur d’une image disque de VM sous ~/Library/Containers, pas ~/Library/Caches, ce qui vaut la peine d’être su pour qu’un nettoyage en bloc de Caches ne crée pas un faux sentiment d’avoir aussi traité Docker. Voir le guide de l’espace disque Docker.

Tout le reste couvert sur ce blog — DerivedData vit techniquement sous ~/Library/Developer, pas ~/Library/Caches, un autre dossier qu’il vaut la peine de connaître, situé juste en dehors du rayon d’action de celui-ci — est soit directement à l’intérieur de ~/Library/Caches, soit régi par le même principe « sûr à régénérer », même quand Apple l’a classé sous un répertoire de premier niveau légèrement différent.

Pourquoi un scan bat quand même une suppression en bloc

rm -rf ~/Library/Caches/* est sûr, mais c’est aussi aveugle — ça ne peut pas vous dire quelles trois applications sont responsables de 40 des 45 Go présents, et ça ne peut pas vous avertir de l’exception IndexedDB de Slack évoquée plus haut avant qu’elle ne se produise. Une répartition octet par octet, triée et nommée, transforme « vider le dossier de cache et espérer » en « voici les quatre choses qui valent réellement la peine d’être connues, dans l’ordre ».

DevCruft, une application Mac gratuite pour développeurs, est en cours de création. Elle est conçue pour lire exactement ce dossier — plus DerivedData, le stockage des conteneurs de Docker, et tout le reste qui vit juste à côté — et vous montrer la même répartition classée que produit la commande du ci-dessus, sauf que chaque entrée sera étiquetée avec ce qu’elle est réellement et si elle est sûre, plutôt qu’un identifiant de paquet que vous devez rechercher à la main. Inscrivez-vous sur la liste d’attente pour savoir quand elle sortira.

Ceci est le dernier de dix guides ajoutés dans cette série. Pour le tour d’horizon original, plus large, de tout ce qui remplit le Mac d’un développeur, commencez par le guide complet du stockage pour développeurs.