Aufräumen, ohne dass es zur Dateisystem-Operation wird
cargo clean kennt ein Projekt. cargo-broom findet die target-Verzeichnisse unter einem ganzen Verzeichnisbaum, bewertet sie nach Alter und Größe und zeigt zuerst, was ein Lauf entfernen würde. Ohne Bestätigung passiert nichts.
$ cargo broom --dry-run --keep-days 0 --keep-size 50MB ~/GitHub/kestrel cargo-broom Summary (Dry Run) Reclaimable: 3.13 GiB ● Level A — Full Target Clean (Coarse) (1) - kestrel-core (3.13 GiB) at /Users/jseidel/GitHub/kestrel/target
cargo clean beantwortet die Frage nicht, die man tatsächlich hat.
Für ein bekanntes Projekt genügt cargo clean. Sobald mehrere Dutzend Checkouts auf der Platte liegen, lautet die Frage anders: Welche davon belegen den Platz, welche sind kalt geworden, und was würde ein geplanter Lauf heute Nacht wegräumen? cargo-broom ergänzt rekursive Suche, Richtlinien nach Alter und Größe, Trockenläufe, interaktive Auswahl und maschinenlesbare Reports.
- 01Erst sehen —
inspectund--dry-runfassen nichts an - 02Dann bestätigen — ohne
--dry-run,--interactiveoder--yesbricht der Lauf vor dem Scan ab - 03Umkehrbar —
--trashverschiebt in den Papierkorb des Systems statt endgültig zu löschen - 04Nachvollziehbar —
--format jsonfür Skripte, Reports und geplante Trockenläufe
Was im Terminal steht.
$ cargo broom inspect ~/GitHub
cargo-broom Inspect — /Users/jseidel/GitHub
Found 3 Rust target directories occupying 4.99 GiB
• kestrel-core 3.13 GiB /Users/jseidel/GitHub/kestrel/target
… zwei weitere Einträge$ cargo broom --dry-run --keep-days 0 --keep-size 50MB ~/GitHub/kestrel
cargo-broom Summary (Dry Run)
Reclaimable: 3.13 GiB
● Level A — Full Target Clean (Coarse) (1)
- kestrel-core (3.13 GiB) at /Users/jseidel/GitHub/kestrel/target
Next steps:
• Run `cargo broom -y` to reclaim 3.13 GiB
$ cargo broom -y$ cargo broom --dry-run --fine-only --clean-incremental --clean-doc ~/GitHub/kestrel
cargo-broom Summary (Dry Run)
Reclaimable: 531.18 MiB
● Level B — Selective / Experimental Fine Clean (1)
- kestrel-core (pruned 0 stale fingerprints, 1 files) — 531.18 MiB
at /Users/jseidel/GitHub/kestrel/target
Next steps:
• Run `cargo broom -y` to reclaim 531.18 MiB
$ cargo broom -yWas in welchem Modus verschwindet.
| Modus | Auswahl | Was entfernt wird |
|---|---|---|
| Standard / Level A | Target ist mindestens --keep-days alt und, sofern gesetzt, mindestens --keep-size groß | Das vollständige, standardmäßige lokale target/ |
| --coarse-only | Dieselbe Richtlinie wie Level A, feine Operationen werden abgelehnt | Das vollständige, standardmäßige lokale target/ |
| --clean-incremental | Targets, die Level A nicht ausgewählt hat | Die Caches unter target/*/incremental |
| --clean-doc | Targets, die Level A nicht ausgewählt hat | Die erzeugte Ausgabe in target/doc |
| --experimental-fine | Targets, die Level A nicht ausgewählt hat | Fingerprints und zugehörige gehashte Artefakte, ausgewählt über experimentelle Alters- und Dublettenheuristiken |
| --toolchains <Liste> | Modifikator für --experimental-fine | Zusätzlich Fingerprints, die mit einem anderen rustc als den genannten gebaut wurden |
| --installed | Modifikator für --experimental-fine | Dasselbe, behält aber jede aktuell über rustup installierte Toolchain |
| --fine-only | Schaltet Level A ab | Nur die ausdrücklich angeforderten feinen Operationen |
| --trash | Modifikator für Level A, mit jeder der obigen Richtlinien | Verschiebt das Target in den Papierkorb des Systems statt es endgültig zu löschen |
Widersprüchliche Kombinationen weist die CLI zurück: --fine-only braucht eine der feinen Operationen, --tests-only, --toolchains und --installed brauchen --experimental-fine.
Wo das Werkzeug bewusst stehen bleibt.
Nur Standard-Targets vollständig
Das vollständige Löschen ist auf ein normales lokales <workspace>/target beschränkt. Geteilte Targets, konfigurierte Überschreibungen, Symlinks und Targets außerhalb des Workspace werden nie im Ganzen entfernt.
Kein Rückfall auf die grobe Stufe
Scheitert das Lesen eines Fingerprints, überspringt cargo-broom die feine Reinigung für dieses Projekt. Es löscht in diesem Fall nicht ersatzweise das ganze Target.
mtime statt atime
Das Alter wird an der mtime gemessen. Auf noatime- und relatime-Mounts wird atime nicht bei jedem Lesen aktualisiert – Artefakte wirkten dort fälschlich frisch. Die mtime schreibt jeder echte Cargo-Build.
Laufende Builds werden ausgelassen
Ein Target, das gerade von einem Cargo-Prozess gesperrt ist, wird auf beiden Stufen komplett übersprungen, statt mit dem Build um die Dateien zu konkurrieren.
Bestätigung ist nicht konfigurierbar
Absichtlich: Ein unbeaufsichtigter, löschender Lauf muss --yes im Befehl selbst tragen. Die Konfigurationsdatei kann das nicht abkürzen.
Fehler bleiben sichtbar
Fehler beim Löschen werden gemeldet und führen zu einem Exit-Code ungleich null. JSON-Reports gehen nach stdout, Prozessfehler nach stderr.
Vier Kommandos, die nichts löschen.
Bestandsaufnahme
Listet die gefundenen Targets mit ihrem Platzbedarf, ohne eine Richtlinie anzuwenden.
Diagnose
Meldet konfigurierte Target-Überschreibungen, ungewöhnlich große Targets und gesperrte Targets.
Toolchains
Zeigt installierte rustup-Toolchains, die unterhalb des Verzeichnisses von keiner rust-toolchain-Datei referenziert werden. Deinstalliert nichts.
Budget
Summiert den Platzbedarf über alle gefundenen Projekte und weist mit --limit aus, wenn das Budget überschritten ist – samt der größten Posten.
Erst schauen, dann bestätigen.
- 1Installieren
Von crates.io
Die Kiste liegt als
cargo-broomauf crates.io und ist nach der Installation alscargo broomverfügbar. Wer den aktuellen Hauptzweig will, installiert stattdessen direkt aus dem Repository. Voraussetzung ist Rust 1.89 oder neuer.cargo install cargo-broom # oder direkt aus dem Repository cargo install --git https://github.com/casoon/broom.git - 2Schauen
inspect und Trockenlauf
Beide Befehle ändern nichts.
inspectzeigt den Bestand, der Trockenlauf zeigt, was die aktuelle Richtlinie auswählen würde.cargo broom inspect ~/GitHub cargo broom --dry-run ~/GitHub - 3Aufräumen
Bestätigter Lauf
Erst mit
--yesoder--interactivewird gelöscht.--trashmacht denselben Lauf umkehrbar, weil die Targets im Papierkorb landen.cargo broom --yes --keep-days 14 --keep-size 50MB ~/GitHub
Konfiguration und geplanter Lauf.
root_path = "~/GitHub"
keep_days = 14
keep_size_mb = 50
# Für unbeaufsichtigte Läufe bleibt das Experimentelle aus.
experimental_fine = false
fine_only = false
coarse_only = false
trash = false
history = false
hidden = false
ignore = ["archived-repo"]
skip = ["node_modules"]cargo broom --yes --keep-days 14 --keep-size 50MB \
--clean-incremental --clean-doc --history --color never ~/GitHubWofür cargo-broom nicht gedacht ist.
Das Repository benennt die Grenzen selbst – einige davon sind der Grund für die konservative Voreinstellung.
Nicht für CI-Caches
Ein über Läufe hinweg gehaltenes target/ wächst aus einem anderen Grund: Jeder Abhängigkeits-Bump lässt Fingerprints des vorigen Cargo.lock zurück. Das verlangt Invalidierung über Cache-Schlüssel, keine Altersheuristik. Das README verweist auf Swatinem/rust-cache, sccache und cargo-chef.
Fingerprint-Pruning ist experimentell
--experimental-fine ist standardmäßig aus und gehört zuerst in einen geprüften Trockenlauf – nicht in einen unbeaufsichtigten Job.
Version 0.1.0
Eine Alpha mit Sicherheitsfokus. Konservatives Target-Aufräumen, Inspektion, JSON-Reports und selektives Cache-Aufräumen sind vorhanden.
Aktive Projekte fallen durch das Altersraster
rust-analyzer führt cargo check aus, sobald ein Projekt im Editor offen ist, und frischt das Target laufend auf. Ohne --clean-incremental und --clean-doc landet ein solches Projekt auf Skipped und gibt nichts frei, egal wie groß sein Target ist.
Die Registry-Bereinigung sieht nur unterhalb des Verzeichnisses
registry wertet die Cargo.lock-Dateien unter dem angegebenen Verzeichnis aus. Projekte außerhalb zählen nicht mit – deshalb der Trockenlauf über die breitest mögliche Wurzel.
Wiederherstellung heißt neu bauen
Entfernt werden ausschließlich erzeugte Cargo-Ausgaben. Sie sind reproduzierbar, aber der nächste Build dauert entsprechend länger.
--toolchains und --installed ist aus cargo-sweep (MIT) übernommen, das seinerseits Cargos internen Fingerprint-Hash nachbildet.Lizenztext im Repository →Häufige Fragen.
Kann ein Lauf etwas löschen, das nicht wiederherstellbar ist?
Entfernt werden ausschließlich erzeugte Cargo-Ausgaben, die ein Build neu erzeugt. Zusätzlich verschiebt --trash die Targets in den Papierkorb des Systems statt sie endgültig zu löschen. Was bleibt, sind längere Build-Zeiten nach dem Aufräumen.
Was passiert, wenn ich die Bestätigung vergesse?
Ein Aufruf ohne --dry-run, --interactive oder --yes bricht ab, bevor der Scan der Projekte überhaupt beginnt. Die Bestätigung lässt sich bewusst nicht in der Konfigurationsdatei hinterlegen.
Warum gibt ein Lauf bei meinem aktiven Projekt nichts frei?
Level A entfernt ein Target erst, wenn darin keep_days lang nichts angefasst wurde. rust-analyzer frischt das Target bei geöffnetem Editor laufend auf, also greift das Altersraster nie. Für solche Projekte sind --clean-incremental und --clean-doc gedacht: Beide Cache-Verzeichnisse baut Cargo bei Bedarf neu.
Wie oft sollte ein geplanter Lauf laufen?
Das README empfiehlt alle zwei Tage statt wöchentlich, weil inkrementelle Caches innerhalb von Stunden nachwachsen und der Lauf selbst günstig ist. Auf macOS ist StartCalendarInterval auf ungeraden Tagen zuverlässiger als StartInterval, dessen Timer bei jedem Neustart von vorn beginnt.
Was macht --experimental-fine genau?
Es entfernt einzelne Fingerprints und die dazu passenden gehashten Artefakte, ausgewählt über Alters- und Dublettenheuristiken. Jeder Eintrag wird gegen seine eigene Fingerprint-JSON geprüft, statt sich auf die Benennung des .fingerprint-Verzeichnisses zu verlassen. Ist keine JSON lesbar, gilt das Projekt als nicht unterstützt, statt zu raten.
Was schreibt --history mit?
Je Lauf eine Zeile pro Target mit der resultierenden Größe, in ein rollendes 14-Tage-Log unter ~/.local/state/cargo-broom/history.jsonl. Trockenläufe werden nie aufgezeichnet. Ab dem zweiten Eintrag zeigt der Report eine History-Metrik – also ob ein Target trotz regelmäßigem Aufräumen wieder wächst.
Erst der Trockenlauf.
Installieren, inspect über den eigenen Projektbaum laufen lassen und sehen, wie viel dort tatsächlich liegt.