Trouver et retirer de gros fichiers Mac en sécurité

La façon la plus rapide de savoir ce qui occupe un disque est de le mesurer, pas de parcourir Finder dossier par dossier. La mesure demande encore de l'interprétation : une bibliothèque Photos de 40 Go n'équivaut pas à un installateur de 40 Go, et les snapshots APFS, les clones et la capacité purifiable peuvent faire en sorte que deux outils corrects affichent des totaux d'apparence différente.

Voici comment l'espace disque est comptabilisé, comment le mesurer, et comment trouver les gros éléments en toute sécurité.

Pourquoi le disque est plein alors que les fichiers ne collent pas

Les Mac modernes utilisent le système de fichiers APFS, et APFS rend compte de l'espace différemment de ce que montre Finder. Deux catégories cachent des gigaoctets :

• Snapshots locaux. Time Machine conserve des snapshots ponctuels de votre disque sur le volume interne entre les sauvegardes. Ils figent l'espace des fichiers que vous avez déjà supprimés, car le snapshot les référence encore, jusqu'à ce que macOS les allège. Apple indique que les snapshots horaires sont normalement conservés environ 24 heures et supprimés automatiquement en vieillissant ou lorsque de l'espace est nécessaire. Listez-les avec :

tmutil listlocalsnapshots /

• Espace purifiable. APFS marque les caches, les snapshots locaux et le contenu re-téléchargeable comme purifiables : de l'espace que macOS récupère de lui-même lorsqu'il en a besoin. macOS peut le compter comme disponible, et Finder peut l'inclure dans le total disponible. Vous ne pouvez pas le libérer de façon fiable à la main.

Vérifiez les chiffres avec :

df -h /
diskutil apfs list
diskutil apfs listSnapshots /

df indique ce que le système de fichiers monté considère comme utilisé et disponible. diskutil apfs list montre le conteneur partagé, ses volumes et la capacité restante. diskutil apfs listSnapshots / liste les snapshots rattachés au volume de démarrage. Quand Finder indique un disque plus plein que ne l'expliquent vos fichiers, ces vues aident à séparer l'usage ordinaire des fichiers des snapshots et de la capacité APFS partagée.

Mesurer l'usage réel en ligne de commande

Pour trouver les dossiers lourds, du (disk usage) est l'outil central. Depuis votre dossier personnel :

du -sh ~/* ~/Library 2>/dev/null | sort -h

-s donne un résumé par élément, -h affiche des tailles lisibles, et le pipe vers sort -h place les plus gros en dernier. Descendez dans un gros résultat à la fois. Terminal peut avoir besoin de l'Accès complet au disque pour les données d'apps protégées, et un scan du dossier personnel peut prendre longtemps lorsqu'il traverse des dossiers cloud ou des arbres de développement.

Le chiffre n'est pas toujours l'allocation physique. Les hard links donnent plusieurs noms au même fichier sous-jacent, et les clones APFS partagent des blocs jusqu'à ce qu'une copie change. Les totaux de dossiers et l'espace libre du conteneur peuvent donc répondre à des questions différentes. Utilisez du pour repérer les candidats, puis le menu Lire les informations de Finder et la vue de capacité APFS avant une suppression à fort impact.

Pour trouver des fichiers individuels volumineux plutôt que des dossiers, find filtre par taille :

find ~/Downloads ~/Movies ~/Desktop -type f -size +500M -print 2>/dev/null

Commencez par les dossiers sous votre contrôle plutôt que de scanner tout le répertoire personnel. La commande attrape les exports vidéo oubliés, les images disque et les archives sans se perdre dans chaque base de données d'application. Élargissez la liste des racines uniquement si nécessaire. Pour une carte interactive en terminal, ncdu peut parcourir un dossier choisi par taille. Traitez-le d'abord comme un outil de découverte en lecture seule ; révélez un candidat dans Finder et déplacez-le vers la Corbeille après l'avoir identifié, plutôt que de supprimer depuis un arbre inconnu dans ncdu.

Récupérer l'espace caché

Si le problème vient des snapshots ou de l'espace purifiable plutôt que d'un seul fichier, libérer de l'espace réellement sous votre contrôle donne à macOS de la marge pendant qu'il vieillit ou allège automatiquement les snapshots locaux et les caches purifiables. Reconnecter un disque Time Machine rend plus d'historique de sauvegarde disponible, mais ce n'est pas une commande manuelle de purge de snapshots. Vous avez rarement besoin de forcer l'une ou l'autre catégorie à la main.

Une carte visuelle, quand une liste ne suffit pas

Les tailles en terminal sont utiles, mais difficiles à tenir en tête sur un disque entier. Un treemap résout cela en dessinant chaque dossier comme un rectangle proportionnel à sa taille, de sorte que les plus gros éléments sont les plus gros blocs et qu'un coup d'œil suffit pour voir où se trouve le poids. La vue Analyze de Mole est le pendant graphique de la marche par chemin ci-dessus : elle cartographie le disque entier depuis la racine, descend d'un clic, et vous permet de révéler un élément dans Finder ou de l'envoyer à la Corbeille (depuis le menu contextuel, avec confirmation de la taille, et récupérable jusqu'à ce que la Corbeille soit vidée). Les racines de navigation comme votre dossier personnel n'ont pas d'option de suppression, donc un clic maladroit ne peut pas retirer quelque chose de structurel. Utilisez ce que vous préférez ; le treemap et les commandes répondent à la même question.

Sous le capot : comment un analyseur de disque reste rapide

Vous n'avez pas besoin de cette partie pour libérer de l'espace, mais si vous vous êtes déjà demandé pourquoi une bonne carte de disque répond en quelques secondes là où un script naïf rampe, voici la forme de la chose. L'exemple est l'outil en ligne de commande open source de Mole, plus précisément son analyseur Go dans cmd/analyze. L'app native a un scanner Swift distinct, mais les deux maintiennent la concurrence bornée et dédupliquent les hard links.

La façon lente est l'évidente : parcourir chaque dossier, faire un stat sur chaque fichier, tout additionner, puis trier. Sur un dossier personnel avec des millions de petits fichiers, c'est à la fois lent et gourmand en mémoire. Le scanner évite les deux pièges avec trois idées.

Borné, mais pas avec une seule limite. Le parallélisme naïf lance une goroutine par dossier et fait fondre le disque. Le scanner maintient plutôt des budgets séparés pour des ressources séparées : un pool de workers de dossiers (2 à 12, proportionnel à vos cœurs), un pool bien plus petit d'au plus quatre sous-processus du concurrents (parce que du est déjà parallèle en E/S, et en lancer davantage ne fait que thrash le disque), et une borne de file pour que le travail en attente ne gonfle jamais en milliers de goroutines empilées. Fusionner tout cela en une seule limite, c'est ainsi que les outils disque finissent soit lents, soit gourmands en mémoire.

Ne garder que les gagnants. Vous voulez les plus gros dossiers, pas tous, donc le scanner ne trie jamais le disque entier. Il fait streamer chaque élément mesuré à travers deux min-heaps, l'un tenant les Top 30 dossiers et l'autre les Top 20 fichiers. Quand un heap est plein, un nouvel élément est comparé au plus petit survivant et écarté s'il ne le bat pas. C'est à peu près linéaire en nombre de fichiers et ne conserve que quelques dizaines d'entrées en mémoire, au lieu de trier des millions.

Compter chaque octet une seule fois. Un fichier avec plusieurs hard links serait autrement additionné une fois par lien. Le scanner enregistre la paire (device, inode) de chaque fichier la première fois qu'il le voit et ignore les répétitions, ce qui fait coller ses totaux à du. Il refuse même de mettre en cache un total de dossier qui dépendait de cette déduplication, car ce chiffre dépend de l'ordre de scan et empoisonnerait un re-scan autonome ultérieur.

Rien de tout cela n'est exotique. C'est la différence entre un outil qui répond « qu'est-ce qui remplit mon disque » en quelques secondes et une boucle shell qui n'y parvient pas, et le treemap ci-dessus est le front-end exact de ce moteur.

Classer avant de supprimer quoi que ce soit

Trouver un gros élément n'est pas une autorisation de le supprimer. Placez chaque candidat dans l'un de ces trois seaux :

• Remplaçable : installateurs vérifiés, sorties de build reproductibles et caches documentés. Vérifiez le coût de les re-télécharger ou de les reconstruire avant la suppression.
• Personnel ou opérationnel : photos, messages, archives de projets, disques de machines virtuelles, poids de modèles et sauvegardes d'appareils. Exportez, sauvegardez ou retirez-les via l'app propriétaire.
• Géré par l'app ou le système : bases de paquets, conteneurs, bibliothèques Photos ou Mail, snapshots, et tout ce qui se trouve sous /System. Utilisez les contrôles de l'app ou laissez-le tranquille.

Si un gros dossier appartient à une app que vous n'utilisez plus, suivez son désinstallateur documenté, puis examinez ses restes. Déplacez d'abord les fichiers ordinaires vers la Corbeille et gardez-les-y tant que l'app et le projet concernés fonctionnent encore. Vider la Corbeille est l'étape irréversible.

Pour un nettoyage plus large au-delà des seuls gros fichiers, voir comment libérer de l'espace sans perdre de fichiers.

Une méthode répétable

Comparez d'abord df, la capacité APFS et les réglages de stockage pour savoir si le problème est une vraie pression physique ou une question de classification. Ensuite, mesurez des racines choisies, descendez dans la plus grosse branche, et classifiez le candidat selon la propriété et la récupérabilité. Supprimez d'abord les données remplaçables, traitez les données personnelles via des sauvegardes et les apps propriétaires, et gardez les suppressions ordinaires récupérables dans la Corbeille jusqu'à avoir vérifié le résultat.