Symlink-Fallen beim Auslagern: acht Fehler, die du vermeiden kannst

Ein symbolischer Link ist eine winzige Datei, die nur einen Pfad enthält. Programme, die über diesen Link eine Datei oder einen Ordner öffnen, landen am Ziel, meist ohne es zu bemerken. Genau das macht Links zum Standardwerkzeug beim Auslagern auf eine externe SSD: Xcode, Node oder dein Editor greifen weiter auf den gewohnten Pfad zu, während die Daten woanders liegen. Dieselbe Unauffälligkeit hat eine Kehrseite. Fehler beim Verlinken fallen oft erst auf, wenn ein Build scheitert oder Daten an einer unerwarteten Stelle liegen.

Symlink, Alias, Hardlink: kurz sortiert

Für das Auslagern auf ein anderes Laufwerk kommt nur der symbolische Link infrage. Hardlinks können keine Laufwerksgrenzen überspringen und lassen sich unter APFS nicht für Ordner anlegen. Aliasse ignorieren Terminal und Entwicklerwerkzeuge.

Die acht häufigsten Fallen

1. Reihenfolge vertauscht

ln -s erwartet zuerst das Ziel und danach den Ort des Links, zum Beispiel ln -s /Volumes/Arbeit-SSD/Projekte ~/Projekte. Eine Eselsbrücke: dieselbe Reihenfolge wie bei cp, erst das Vorhandene, dann das Neue. Vertauschst du die Angaben, entsteht der Link an der falschen Stelle, oder der Befehl bricht mit „File exists“ ab.

2. Der Link landet im Ordner

Existiert am gewünschten Ort noch ein Ordner, legt ln -s den Link darin an, statt ihn zu ersetzen. Das Ergebnis ist ein Eintrag wie ~/Projekte/Projekte, während der alte Ordner unverändert bleibt. Benenne das Original deshalb vorher um und prüfe danach mit ls -l, was wirklich entstanden ist.

3. Relativer Pfad falsch aufgelöst

Ein relativer Pfad im Link wird vom Ort des Links aus gelesen, nicht von dem Ordner, in dem dein Terminal gerade steht. Ein Link, der im Moment des Anlegens scheinbar funktioniert, kann deshalb ins Leere zeigen. Für Links auf eine externe SSD verwendest du immer den vollständigen Pfad ab /Volumes.

4. Löschen mit Schrägstrich am Ende

Diese Falle kann Daten kosten. rm -r ~/Projekte/ mit abschließendem Schrägstrich folgt dem Link und kann den Inhalt auf der SSD treffen. Einen Link entfernst du mit rm ~/Projekte oder unlink ~/Projekte, ohne -r und ohne Schrägstrich. Das Gleiche gilt für Aufräumskripte, die Ordner rekursiv löschen: Prüfe, ob sie Links folgen, bevor du sie auf ausgelagerte Ordner loslässt.

5. Alias statt Link

Ein Alias aus dem Finder sieht aus wie ein Link und verhält sich im Finder ähnlich. Terminal, Compiler, Paketmanager und Build-Werkzeuge sehen darin aber nur eine gewöhnliche Datei. Für ausgelagerte Arbeitsordner taugt ein Alias deshalb nicht.

6. Die SSD heißt plötzlich anders

macOS bindet externe Laufwerke unter /Volumes mit ihrem Namen ein. Benennst du die SSD um, zeigt jeder Link weiter auf den alten Namen. Hängt ein zweites Laufwerk mit gleichem Namen am Mac oder ist nach einem unsauberen Trennen ein Rest unter dem alten Namen übrig, erscheint die SSD mit angehängter Ziffer, etwa als Arbeit-SSD 1. Der Link führt dann ins Leere oder im ungünstigsten Fall an einen falschen Ort. Worauf es im Alltag mit einer dauerhaft angeschlossenen SSD ankommt, beschreibt die Seite Externe SSD dauerhaft am Mac.

7. Werkzeuge merken sich den echten Pfad

Viele Programme lösen einen Link auf und arbeiten danach mit dem echten Pfad unter /Volumes. Manche speichern diesen Pfad in Caches, Projektdateien oder Konfigurationen. Solange die SSD angeschlossen ist, fällt das nicht auf. Ziehst du die Daten später zurück, zeigen solche Einträge weiterhin auf die SSD. Plane nach jedem Umzug einen kurzen Testlauf ein und lösche bei Bedarf die Caches des betroffenen Werkzeugs.

8. Doppelt verlinkt

Ist ein Ordner bereits ein Link, verschiebt mv nur den Link und nicht die Daten. Wer einen schon ausgelagerten Ordner ein zweites Mal auslagert, baut schnell Ketten aus Links, die niemand mehr durchschaut. Prüfe vor jedem Umzug mit ls -ld, ob die Quelle ein echter Ordner ist.

Wann ein Link die falsche Lösung ist

Nicht jeder große Ordner sollte per Link auf eine SSD umziehen. Bietet ein Werkzeug eine eigene Einstellung für seinen Speicherort, ist sie meist die bessere Wahl, etwa Settings → Locations in Xcode für DerivedData oder npm config set cache für den npm-Cache. Ordner, die ein Systemdienst verwaltet, gehören gar nicht in einen Link: Simulator-Runtimes verwaltest du in Xcode unter Settings → Components, das Festplattenabbild von Docker Desktop über dessen Einstellung Disk image location. Und Daten, die du unterwegs brauchst, bleiben besser intern, denn ohne angeschlossene SSD führt jeder Link ins Leere.

Ein Link lohnt sich vor allem für große, passive Arbeitsordner ohne eigene Einstellung: Projektordner, Archive, Medienbibliotheken oder Paket-Caches, die du am Schreibtisch brauchst, aber nicht auf der internen SSD.

So prüfst du einen Link

ls -l ~/Projekte zeigt einen Link mit einem Pfeil auf sein Ziel. readlink ~/Projekte gibt nur das Ziel aus. Wechselst du mit cd ~/Projekte hinein, zeigt pwd -P den tatsächlichen Pfad auf der SSD. Im Finder erkennst du Links und Aliasse an einem kleinen Pfeil im Symbol.

Ein Punkt wird dabei oft übersehen: Time Machine sichert einen symbolischen Link als Link, nicht die Daten, auf die er zeigt. Die Daten auf der SSD brauchen deshalb eine eigene Sicherung. Ein Link ersetzt kein Backup, er verlegt nur den Ort deiner Arbeitsdaten.

Was DevSpace Manager hier absichert

DevSpace Manager, eine macOS-App von BRUNIQO, legt den Link nicht per Hand an, sondern bereitet ihn vor und schaltet erst nach einem vollständigen Dateivergleich um. Die App speichert die Identität des Ziel-Volumes und blockiert Änderungen, wenn die SSD fehlt oder eine falsche angeschlossen ist. Bereits verlinkte Quellen, Netzwerklaufwerke und interne Ziele schließt sie aus. Das Original bleibt als Quarantäne für einen möglichen Rollback erhalten. Wie derselbe Ablauf von Hand aussieht, zeigt die Anleitung zum Auslagern. DevSpace Manager ist für den Mac App Store vorgesehen und derzeit noch nicht veröffentlicht; die Übersicht zu DevSpace Manager fasst die Funktionen zusammen.