Hyperspace: Mac-App zum Sparen von Speicherplatz ohne Dateilöschung

 (hypercritical.co)
1 Punkte von GN⁺ 2025-02-26 | 1 Kommentare | Auf WhatsApp teilen
  • Das Bereinigen doppelter Dateien auf dem Mac setzt normalerweise das Löschen voraus, aber Hyperspace nutzt APFS-Klone, damit Dateien mit identischem Inhalt Daten gemeinsam nutzen und so Speicherplatz zurückgewonnen wird, ohne die Dateien zu entfernen
  • Copy-on-Write-Klone in APFS ermöglichen es wie „Duplicate“ im Finder, große Dateien fast sofort zu duplizieren, ohne die eigentlichen Daten erneut zu schreiben, da Original und Kopie dieselben Daten teilen
  • Als die Festplatte des Entwicklers vollzulaufen begann, schrieb er ein Perl-Skript, das Dateien mit identischem Inhalt, aber ohne Klonbeziehung, findet; das mögliche Einsparpotenzial lag bei mehreren Dutzend GB, woraus schließlich die App entstand
  • Die App kann kostenlos heruntergeladen werden, um zu scannen und das mögliche Einsparpotenzial anzuzeigen, für die tatsächliche Rückgewinnung von Speicherplatz ist jedoch eine kostenpflichtige Zahlung erforderlich
  • Da sie Dateien verändert, die sie weder erstellt hat noch besitzt, ist das Risiko hoch; zugleich kann sie vielen Mac-Nutzern ganz praktisch helfen

Speicherplatz zurückgewinnen, ohne Dateien zu entfernen – mit APFS-Klonen

  • Hyperspace erkennt Dateien mit identischem Inhalt, die keine Klonbeziehung zueinander haben, und wandelt sie in APFS-Klone um, sodass auf der Festplatte nur noch eine gemeinsame Datenkopie gespeichert wird
  • Bestehende Mac-Apps für doppelte Dateien sparen Speicherplatz meist, indem sie Duplikate löschen; Hyperspace gewinnt Speicherplatz zurück, ohne Dateien zu entfernen
  • Zu den Kernfunktionen von APFS gehören zeitpunktbezogene Snapshots und Copy-on-Write-Klone
    • Snapshots werden verwendet, um Time-Machine-Backups robuster und effizienter zu machen
    • Copy-on-Write-Klone basieren auf einer flexiblen Struktur zwischen Verzeichniseinträgen und Dateiinhalten
  • Wenn man im Finder eine Datei mit dem Befehl „Duplicate“ dupliziert, wird der eigentliche Dateiinhalt nicht kopiert; stattdessen entsteht eine Klondatei, die sich die Daten mit dem Original teilt
    • Dank dieser Struktur ist das Duplizieren im Finder unabhängig von der Dateigröße nahezu sofort abgeschlossen

Veröffentlichung und Entwicklungsnotizen

  • Als die Mac-Festplatte des Entwicklers Ende 2024 vollzulaufen begann, schrieb er ein Perl-Skript, das Dateien mit identischem Inhalt, aber ohne Klonbeziehung, findet und in Klone umwandelt
    • Dieses Skript ruft ein in C geschriebenes Kommandozeilen-Tool und ein in Swift geschriebenes Kommandozeilen-Tool auf
    • Das Ergebnis zeigte ein mögliches Einsparpotenzial von mehreren Dutzend GB, woraus später eine Mac-App wurde
  • Hyperspace ist im Mac App Store erhältlich
    • Download und Scan sind kostenlos
    • Für die tatsächliche Rückgewinnung von Speicherplatz ist ein In-App-Kauf erforderlich
    • Weitere Details finden sich in der Hyperspace-Dokumentation
  • Aus Entwicklungssicht ist Hyperspace die zweite SwiftUI-Mac-App des Entwicklers und die erste App, die den SwiftUI life cycle verwendet
    • Es ist auch seine zweite App mit Swift 6
    • Von Anfang an Swift 6 zu verwenden, war deutlich einfacher, als eine bereits veröffentlichte App auf Swift 6 umzustellen
    • In Swift 6 gibt es noch einige raue Kanten, bei denen er auf künftige Verbesserungen hofft
  • Hyperspace verändert Dateien, die die App weder erstellt hat noch besitzt, ähnlich wie beim Umstieg von HFS+ auf APFS
    • Der Entwickler bezeichnet sie als die gefährlichste App, die er je entwickelt hat
    • Zugleich hält er sie für eine App, die für die meisten Menschen am nützlichsten sein könnte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-02-26
Hacker-News-Kommentare

  • Ich habe früher das Kommandozeilen-Utility dedup gebaut, das dasselbe macht
    Es hat einen Dry-Run-Modus, wählt „intelligent“ die beste Clone-Quelle aus, versteht Hard Links und andere Clones, bewahrt Metadaten und behandelt auch HFS-komprimierte Dateien korrekt
    Meine Daten hat es bisher noch nicht kaputtgemacht, aber wie bei Dateisystem-Tools immer gilt: Nutzung auf eigenes Risiko
    0 - https://github.com/ttkb-oss/dedup

    • Ich schreibe das, nachdem ich nur gescannt und noch nicht dedupliziert habe, aber bei einem 7,6-GB-Workspace mit Disk-Images, Programmbinaries und Zwischenrepräsentationen ist der Unterschied schon deutlich
      Hyperspace scannt standardmäßig nicht alle Dateien, sondern nur Dateien auf einer Allowlist, und die Struktur wirkt so, als müsse sie den Dateiinhalt verstehen. Aus Sicht eines Endnutzers ist mir nicht klar, wie zwischen Textdateien und Source-Code-Dateien unterschieden wird; beim Standardscan wurden nur 360 MB als Kandidaten für Deduplizierung gefunden, mit Zulassung aller Dateien stieg das aber auf 842 MB
      Standardmäßig werden auch Dateien unter 100 KB nicht gescannt; wenn man die Größenbeschränkung abschaltet und alle Dateien zulässt, steigt das auf 1,1 GB. Ohne Begrenzung bei Dateitypen und -größen hat Hyperspace 67.309 von 68.874 Dateien gescannt, dedup 67.426
      Hyperspace meldete 29.522 Dateien als deduplizierbar, dedup fand 29.447. Es gibt außerdem 76 bereits deduplizierte Dateien, also bleibt eine Abweichung von eins, deren genaue Ursache ich nicht kenne
      Die Scan-Zeit lag bei Hyperspace bei etwa 50 Sekunden, bei dedup bei 14 Sekunden. Hyperspace scheint erst das Dateisystem zu scannen, dann Deduplikate zu berechnen und erst danach zu deduplizieren; ich weiß nicht, warum die ersten beiden Schritte nicht zusammengelegt werden. Ich habe es so gebaut, dass beim Scannen Dateisystem-Metadaten in eine Queue gelegt werden und die Deduplikatberechnung parallel startet; in den meisten Fällen lassen sich Unterschiede schon allein über die Größeninformationen herausfiltern, die man beim Durchlaufen der Verzeichnisse mit fts_read quasi „gratis“ bekommt
      Hyperspace meinte, es ließen sich 1,1 GB sparen, dedup fand 1,04 GB plus bereits eingesparte 882 MB. Ich habe nicht vor, Hyperspace zu kaufen, daher weiß ich nichts über die tatsächliche Deduplizierungszeit, die Metadatenerhaltung oder den Umgang mit seltsamen Dateien, aber dedup brauchte für Scan und Deduplizierung zusammen 31 Sekunden
      Selbst nach der Deduplizierung mit dedup meint Hyperscan noch, dass es 2 Dateien gibt, die weiterhin deduplizierbar sind. Hyperspace scheint auch Dateien mit mehreren Hard Links, leere Dateien und verschiedene Ausnahmefälle zu behandeln, die dedup prüft. Ob ACLs oder andere Attribute erhalten bleiben, kann ich ohne Bezahlung nicht testen, aber strings deutet darauf hin; HFS-Komprimierung ist ein kniffliger Randfall, und ich konnte noch nicht prüfen, wie Hyperspace-Scans damit umgehen
    • Ich habe es auf etwas wie einem Postgres-Entwicklungsverzeichnis mit vielen fast gleichen Dateien laufen lassen und etwa 1,7 GB gespart
      Das Projekt hat keine Lizenz; wenn möglich, wäre es gut, eine gewünschte Lizenz hinzuzufügen. Ich habe auch einen Pull Request erstellt, um die Installationsschritte etwas zu verbessern: https://github.com/ttkb-oss/dedup/pull/6
    • Gerade ausprobiert, funktioniert gut. Erst als ich gesehen habe, wie viele Duplikate es tatsächlich bei bestimmten Dateitypen gibt, besonders in node_modules, wurde mir das Potenzial dieser Technik klar
      Schon in einem bestimmten Unterverzeichnis war es nicht ungewöhnlich, 50 Kopien irgendeiner JS-Datei zu einer einzigen zusammenzuführen. Da es aber „pre-release“ ist und auf GitHub nicht viele Sterne hat, frage ich mich nach der Stabilität, denn bei solchen Tools sind Bugs ziemlich beängstigend
    • Die Dokumentation ist hervorragend, und auch dass make fast sofort fertig ist war beeindruckend
    • Eine Liste mit Alternativen findet sich in den Kommentaren zu https://news.ycombinator.com/item?id=38113396
      Ich habe früher https://github.com/sahib/rmlint verwendet und hatte nichts daran auszusetzen

  • Der Teil „Hyperspace hat keine Möglichkeit, mit allen anderen Apps oder macOS selbst zusammenzuarbeiten, um einen sicheren Zeitpunkt für den Dateiersatz zu koordinieren, und auch keine Möglichkeit, die betreffende Datei zwangsweise exklusiv zu kontrollieren“ lässt mich fragen, warum nicht das Dateisystem selbst im Hintergrund einen ähnlichen Deduplizierungsprozess ausführt
    Auf dieser Abstraktionsebene sollte man solche Sicherheitsprobleme eigentlich verwalten können; ich frage mich, welche Nachteile es hätte, wenn das automatisch innerhalb von APFS passieren würde

    • Bei ZFS wird dabei viel RAM verwendet. Vermutlich, weil ZFS das auf Blockebene erledigt und deshalb viele Blöcke nachverfolgen muss, um sie beim Schreiben neuer Blöcke zu vergleichen
      Wenn man es auf Dateiebene implementiert, könnte der Ressourcenverbrauch sinken, aber ich weiß nicht, ob die Implementierung dann einfacher oder komplizierter wäre. Außerdem ist es vielleicht nicht intuitiv, dass das Dateisystem bei einer Änderung von nur 1 Byte in einer großen Datei diese Datei erneut duplizieren müsste, was viel zusätzliche Plattenaktivität verursachen kann
    • Bei Blockspeicher macht man so etwas oft zusammen mit Komprimierung. Natürlich scheitert das, wenn das Dateisystem die an das Gerät gesendeten Blöcke verschlüsselt
      Deduplizierung auf dieser Ebene hat den Vorteil, dass man über mehrere Dateisysteme hinweg deduplizieren kann. Wenn es zum Beispiel tausend Systeme mit denselben Betriebssystemdateien gibt, kann man enorm viel Speicherplatz sparen, und oft bestehen die Unterschiede nur aus systemspezifischen Einstellungen wie Host-Keys oder Hostnamen. Ein einzelnes Dateisystem kann solche Gemeinsamkeiten nicht erkennen
      Problematisch wird es allerdings, wenn Deduplizierung die Zahl der Kopien stark genutzter Dateien reduziert. Wenn im obigen Beispiel alle tausend Systeme gleichzeitig booten, kann das zu einer enormen I/O-Last auf dem Kernel-Image führen
    • Unter Linux ist das die Standard-Deduplizierungs-API, die btrfs und XFS verwenden
      Man fordert das Betriebssystem höflich auf, eine angegebene Menge von Bereichen zu deduplizieren, und das OS sperrt die Bereiche, prüft erst, ob sie tatsächlich identisch sind, und führt dann erst die Deduplizierung durch. Man bekommt außerdem pro Bereich ein Feld zurück, das angibt, wie viele Bytes dedupliziert wurden, sodass ein User-Space-Programm Dateien nicht beschädigen kann
    • ZFS macht so etwas tatsächlich: https://www.truenas.com/docs/references/zfsdeduplication/
    • Windows Server bietet diese Funktion ebenfalls auf NTFS- und ReFS-Volumes
      Ich habe sie recht intensiv auf ReFS mit Hyper-V-VMs genutzt, und die Wirkung war enorm. Damals waren es überwiegend VMs mit einer Mischung aus Windows Server 2016/2019, und der Speicherverbrauch sank um etwa 45 %

  • Mir gefällt das Modell, bei dem der Scan kostenlos ist, damit man sehen kann, ob es sich lohnt, und man nur für das tatsächliche Ergebnis bezahlt
    Ich neige auch dazu, Dateien anzusammeln, habe es also ausprobiert, und es wurden 7 GB rückgewinnbar angezeigt, aber für mich war das nicht genug, um dafür Geld auszugeben. Trotzdem finde ich es gut, dass es so ein Tool gibt

    • In einem Podcast wurde dieses Modell einmal erklärt. Viele Nutzer werden das kaufen, einmal ausführen, ein paar GB sparen und es dann nie wieder verwenden, daher ergibt ein Abo wenig Sinn
      Wie viele exakt gleiche Duplikatdateien erstellt man im Monat schon versehentlich?
      Für Leute, die es tatsächlich häufig nutzen, gibt es zwar ein Abo oder eine Dauerlizenz, aber für viele ist ein einmaliger In-App-Kauf für eine begrenzte Nutzungsdauer ziemlich sinnvoll. Und man kann es jederzeit kostenlos erneut laufen lassen, um zu prüfen, ob sich eine weitere Zahlung wieder lohnt
    • Der Wert solcher Deduplizierungs-Apps liegt für mich weniger in der Speicherersparnis als darin, keine doppelten Dateien mehr zu haben
      Ich erzeuge davon keine riesigen Mengen, aber wenn man manche oder alle zusammenzählt, kommen große doppelte Dateien zustande. Das passiert meist in seltsamen Situationen, etwa wenn man Ergebnisse einer Festplattenwiederherstellung mit Dateien an anderen Orten abgleichen muss oder einen chaotischen Download-Ordner mit einem sauber organisierten Zielordner abgleichen will
      Zum Beispiel hat ein Time-Machine-Backup einmal alte Versionen von Dateien ausgespuckt, von denen ich nicht einmal wusste, dass ich Aufzeichnungen davon hatte und die ich längst für verloren hielt, dabei aber die Verzeichnisnamen beschädigt und die Inhalte teilweise verschleiert. Dann hat man Tausende von numerisch benannten Verzeichnissen, in denen sich Dateien befinden könnten, die man behalten möchte, aber es ist völlig unstrukturiert und schwer zu erkennen, ob man sie schon besitzt und wo sie liegen. Umgekehrt enthalten viele davon auch nur eine einzelne Textdatei aus einem Build-System, und so etwas kann man natürlich wegwerfen
    • Bin ich wirklich schon so alt, dass ich mich daran erinnere, dass die meiste Software vor 10 Jahren noch genau so funktioniert hat?
      Haben sich die Leute so sehr an Abo-Fallen gewöhnt, dass ihnen das hier wie ein neues Modell vorkommt?
    • Dieses Preismodell gefällt mir wirklich sehr
      Schön wäre, wenn das auch bei anderer Software leicht umsetzbar wäre, aber meistens steht davor eine Lernkurve, bevor man den Wert überhaupt erkennt
    • Viel erfrischender als eine „kostenlose Testphase“, bei der man daran denken muss zu kündigen
      Als Tipp: Für solche Testversionen kann man eine sperrbare virtuelle Karte verwenden; dann wird die Zahlung blockiert, selbst wenn man das Kündigen vergisst. Ich frage mich allerdings, ob jemand auf der Website den tatsächlichen Lizenzpreis gefunden hat

  • Ich frage mich, welchen Algorithmus die App verwendet, um festzustellen, ob zwei Dateien identisch sind
    Es gibt viele interessante Ansätze wie Hashes, bitweiser Vergleich usw., aber jeder hat seine Nachteile. Was ist die beste Methode, wenn es sehr viele Dateien gibt?

    • Ich weiß nicht, was Siracusa genau macht, aber man kann Vermutungen anstellen
      Für jede Kandidatdatei braucht man einen „Schlüssel“, mit dem man prüfen kann, ob sie mit einer anderen Kandidatdatei identisch ist. Es kann Millionen von Dateien geben, also muss der Schlüssel klein und schnell zu erzeugen sein, gleichzeitig aber ohne False Positives auskommen
      Die heute naheliegende Antwort ist der SHA256-Hash des Dateiinhalts. Er ist sehr schnell, mit 32 Byte nicht besonders groß, und die Wahrscheinlichkeit von False Positives oder Kollisionen ist so gering, dass die Welt praktisch eher untergeht, bevor man damit real konfrontiert wird. SHA256 ist für solche Zwecke de facto Standard; es würde mich ziemlich überraschen, wenn etwas anderes verwendet würde
    • https://en.wikipedia.org/wiki/Venti_(software) kommt mir in den Sinn
      Das war ein inhaltsadressiertes Dateisystem, das Hashes zur Deduplizierung nutzte, und weil die Hashes beim Schreiben berechnet wurden, verteilten sich die Performance-Kosten
    • Ich würde die ersten 1024 Byte aller Dateien hashen und nur bei Kollisionen weitergehen
      Dann müsste man nicht jede große Datei vollständig hashen und würde nur Dateien mit gleichem Hash weiter untersuchen

  • Apple liefert außerdem einen modifizierten cp-Befehl mit Unterstützung für das Flag -c, damit man die Klonfunktion von APFS nutzen kann

    • Wenn das verwendete cp das nicht unterstützt, kann man es auch über Python aufrufen
      Zum Beispiel so: import Foundation; Foundation.NSFileManager.defaultManager().copyItemAtPath_toPath_error_(...)

  • Wenn sich Datei A an zwei Orten befindet und man das hier ausführt: Ändert sich dann bei einer Bearbeitung von A_0 auch A_1, oder wird nur der neue Zustand von A_0 materialisiert und A_1 bleibt unverändert?

  • Auffällig fand ich die Stelle, dass Apple vor der Vorstellung von APFS auf der WWDC 2017 im Rahmen einiger iOS-10.x-Updates heimlich alle iPhones testweise auf APFS migrierte und danach wieder auf HFS+ zurückging.
    Ich frage mich, wie man so eine Änderung des Dateisystems zurückrollen kann, wenn etwas schiefgeht. Den Code kann man natürlich gründlich validieren, aber wenn doch etwas passiert, wirkt ein Rollback unmöglich.

    • Wenn ich mich richtig erinnere, ließ sich die Migration von HFS+ zu APFS durchführen, ohne die Datenblöcke anzufassen, indem APFS-Metadatenblöcke und der Superblock parallel auf die Platte geschrieben wurden.
      Bei Apples Testmigration wurde die komplette Migration einschließlich der Erstellung des APFS-Superblocks durchgeführt, aber direkt vor dem Commit gestoppt, also bevor der HFS+-Superblock dauerhaft durch den APFS-Superblock ersetzt wurde. Beim Zurückrollen mussten dann nur die erzeugten APFS-Superblöcke und Metadatenblöcke „einfach“ bereinigt werden.
    • Ich habe mir den betreffenden Teil des Vortrags angesehen [0], aber außer dass es für Konsistenztests gemacht wurde, gibt es kaum Details.
      Ich habe in Produktionsumgebungen schon genug kaputtgehen sehen und weiß nicht, ob ich den Knopf drücken könnte, wenn man mich bitten würde, so eine große Migration auszuführen.
      [0] https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s
    • Es scheint eher an mangelnder Vorstellungskraft zu liegen. Das ist keine Kronjuwelen-Technologie, die nur Apple beherrscht.
      Auch in der Open-Source-Welt gibt es Werkzeuge, die ext-Dateisysteme in btrfs umwandeln, und zwar so, dass (1) ein Rollback möglich ist und (2) das ursprüngliche ext-Dateisystem sogar weiter gemountet werden kann, während das btrfs-Dateisystem verwendet wird.

  • Es beginnt mit einer Geschichte, verengt sich dann auf ein Problem und zeigt anschließend, wie die Lösung dieses Problem wie von Zauberhand beseitigt.
    Ein sehr gutes Beispiel für großartiges Marketing.

  • Ich habe es auf einen riesigen NodeJS-Projektordner losgelassen, aber es hieß, es ließen sich nur 1 GB in einem 8,1-GB-Ordner einsparen.
    Danach habe ich es noch einmal inklusive meines Home-Verzeichnisses laufen lassen, und bei 731K Dateien, 127K Ordnern und 2.755 Zieldateien kamen insgesamt nur 1,3 GB Ersparnis heraus. Das sind gerade einmal 300 MB mehr als beim Lauf nur auf dem NodeJS-Ordner.
    System und Library wollte ich ebenfalls scannen, aber das wurde wegen Berechtigungsproblemen abgelehnt. Ich nutze pnpm als Paketmanager, daher ist die Festplattennutzung vermutlich ohnehin schon fast optimal.
    Die Idee ist nett, aber zum aktuellen Preis schwer zu rechtfertigen; besser wäre es vielleicht als Hintergrundprozess, der etwa einmal im Monat läuft.

    • 1 GB von 8,1 GB heißt doch, dass 12 % des belegten Speichers verschwendet waren, oder? Vielleicht lese ich das falsch.
    • pnpm will ein Drop-in-Ersatz für npm sein und führt automatisch eine Deduplizierung durch.
    • Unter macOS gibt es versiegelte Volumes, deshalb treten bei System und Library Berechtigungsfehler auf.
      https://support.apple.com/guide/security/signed-system-volum...
    • Ich hatte keine Zeit, es selbst auszuprobieren, aber auf den App-Store-Screenshots ist eindeutig eine Option für die zu berücksichtigende minimale Dateigröße zu sehen.
      Das scheint eingeführt worden zu sein, um den Vergleichspuffer zu verkleinern, und möglicherweise lagen die Dateien in node_modules unter diesem Schwellenwert und wurden deshalb nicht berücksichtigt.
    • Ich weiß nicht, wie viel es kostet. Anscheinend ist der Preis nirgends öffentlich angegeben.

  • Ich habe einmal ein ähnliches, aber einfacheres Skript geschrieben, das Dateien mit identischem Inhalt in Hardlinks umwandelt.
    Der Hauptgrund waren Pakete in Python-virtuellen Umgebungen. Man hat oft ähnliche Pakete installiert, und selbst wenn sich die Versionen unterscheiden, sind viele Dateien weiterhin identisch. Einige Pakete wie Numpy, PyTorch und TensorFlow sind ziemlich groß, sodass sich damit spürbar Speicherplatz sparen ließ.
    https://github.com/albertz/system-tools/blob/master/bin/merg...

    • Das verwendet weder Hardlinks noch symbolische Links, sondern die Funktion des Dateisystems zum Erstellen von Copy-on-Write-Klonen [1].
      [1] https://en.wikipedia.org/wiki/Apple_File_System#Clones
    • uv macht das standardmäßig.
      Ich vermute, andere Werkzeuge wie poetry, hatch und pdm ebenfalls, aber ich habe mich zu wenig mit ihrem genauen Verhalten beschäftigt, um das sicher zu sagen.