~/Library/Caches: Der eine Ordner hinter der Hälfte dieses Blogs

Hast du mehr als einen Artikel dieses Blogs gelesen, ist dir ein Muster aufgefallen: DerivedData, Browser-Caches, Electron-App-Caches, CocoaPods, JetBrains-Indizes — ein enormer Anteil davon liegt irgendwo unter einem einzigen Verzeichnis. Es lohnt sich, dieses Verzeichnis einmal direkt anzuschauen, statt App für App.

open ~/Library/Caches

Der Finder versteckt ~/Library standardmäßig — halte Option gedrückt, während du im Finder auf das Menü Gehe zu klickst, um es sichtbar zu machen, oder nutze den obigen open-Befehl, der die Einstellung für versteckte Ordner ganz umgeht.

Warum dieser Ordner existiert und warum er von Natur aus sicher ist

~/Library/Caches ist Apples eigener, dafür vorgesehener Ort — Daten, die jede App regenerieren oder neu herunterladen kann, die das Betriebssystem ausdrücklich unter Speicherplatzdruck bereinigen darf. Das ist keine von Entwicklern erfundene Konvention; es ist ein dokumentierter Teil von Apples Dateisystem-Layout, und jede gut programmierte Mac-App soll ihn für alles Nicht-Essenzielle nutzen.

Genau diese eine Tatsache macht diesen Ordner ungewöhnlich sicher zum pauschalen Leeren, verglichen mit fast jedem anderen Ort auf deiner Festplatte: Per Apples eigenem Design soll hier nichts die einzige Kopie von irgendetwas Wichtigem sein. Die praktischen Ausnahmen — eine Handvoll Apps, die den Caches-Ordner für Daten missbrauchen, die nicht wirklich wegwerfbar sind — sind selten genug, um sie namentlich zu nennen, was dieser Artikel weiter unten tut.

Direktes Auslesen, nach Größe rangiert

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

Auf fast jedem seit über einem Jahr genutzten Mac fördert dieser einzelne Befehl genau dieselben Namen zutage, die in den anderen Guides dieses Blogs behandelt werden: com.apple.Safari, Google/Chrome, org.swift.swiftpm, Homebrew, CocoaPods, pip, JetBrains, plus Dutzende kleinerer Einträge von Apps, an die du nie einzeln denken würdest.

Die Ordnernamen sind fast immer Reverse-DNS-Bundle-Kennungen (com.company.AppName) oder schlichte Paketnamen (pip, Homebrew) — erkennst du einen nicht, verrät dir mdfind "kMDItemCFBundleIdentifier == '<der-name>'" meist, zu welcher installierten App er gehört.

Der pauschal-sichere Ansatz

Für die meisten Leute, die meiste Zeit, ist das tatsächlich völlig in Ordnung:

rm -rf ~/Library/Caches/*

Jede gut programmierte App baut das, was sie aus diesem Ordner braucht, beim nächsten Start neu auf — das ist der ganze Sinn der Existenz dieses Verzeichnisses. Die sichtbaren Kosten sind die Summe jeder einzelnen an anderer Stelle in diesem Blog behandelten Kosten: Browser rufen Ressourcen erneut ab, Paketmanager laden bei der nächsten Installation erneut herunter, Xcodes Index baut sich neu auf, und so weiter — nichts geht kaputt, mehrere Dinge sind kurzzeitig langsamer.

Die Ausnahmen, die man namentlich kennen sollte

Eine kleine Zahl von Apps nutzt ihren Caches-Unterordner für Daten, die teurer zu verlieren sind, als das Wort „Cache” vermuten lässt, ausführlicher behandelt in ihren eigenen Artikeln:

• Slacks IndexedDB kann unversendete Entwurfsnachrichten enthalten — siehe den Guide zu Slack und Discord.
• Die IndexedDB jeder App, die als lokale Primärspeicherung genutzt wird (manche PWAs, manche Notiz-Apps) — siehe den Browser-Cache-Guide.
• Dockers Cache liegt technisch komplett außerhalb dieses Ordners — er steckt in einem VM-Festplattenimage unter ~/Library/Containers, nicht unter ~/Library/Caches, was wissenswert ist, damit ein pauschales Leeren von Caches nicht den falschen Eindruck erweckt, auch Docker erledigt zu haben. Siehe den Docker-Speicherplatz-Guide.

Alles andere, das dieser Blog behandelt — DerivedData liegt technisch unter ~/Library/Developer, nicht unter ~/Library/Caches, ein weiterer Ordner, den man kennen sollte und der genau außerhalb dieses hier liegt — ist entweder direkt in ~/Library/Caches oder folgt demselben Prinzip „sicher zu regenerieren”, auch wenn Apple es unter einem leicht anderen Top-Level-Verzeichnis abgelegt hat.

Warum ein Scan einem pauschalen Löschen trotzdem überlegen ist

rm -rf ~/Library/Caches/* ist sicher, aber auch blind — es kann dir nicht sagen, welche drei Apps für 40 der 45 GB dort verantwortlich sind, und es kann dich nicht vor der oben genannten Slack-IndexedDB-Ausnahme warnen, bevor sie passiert. Eine byte-genaue Aufschlüsselung, sortiert und benannt, macht aus „Cache-Ordner leeren und hoffen” ein „hier sind die vier tatsächlich wissenswerten Dinge, der Reihe nach.”

DevCruft, eine kostenlose Mac-App für Entwickler, ist gerade in Entwicklung. Es soll genau diesen Ordner lesen — plus DerivedData, Dockers Container-Speicher und alles andere, das direkt außerhalb davon liegt — und dieselbe rangierte Aufschlüsselung zeigen, die der obige du-Befehl liefert, nur mit jedem Eintrag beschriftet, was er tatsächlich ist und ob er sicher ist, statt einer Bundle-Kennung, die du selbst nachschlagen musst. Trag dich in die Warteliste ein, wenn du erfahren willst, wann es erscheint.

Das ist der letzte von zehn in dieser Runde hinzugefügten Guides. Für die ursprüngliche, breitere Tour durch alles, was den Mac eines Entwicklers füllt, beginne mit dem vollständigen Entwickler-Speicherplatz-Guide.