undo in der Anwendung: Wie libundo.so rm- und chmod-Fehler in der Shell rueckgaengig macht

Befehlsgenau statt zeitgenau: Wie sich undo von Snapshots unterscheidet

Die Shell hat bislang keine Undo-Funktion, und das uebliche Advice lautet, dass ueberschriebene Daten verloren sind. Die existierenden Loesungen verlangen laut README zuerst eine Gewohnheitsaenderung: rm auf einen Papierkorb-Befehl alisieren oder vor dem Unfall btrfs- beziehungsweise zfs-Snapshots einrichten. undo fragt nichts ab. Der Nutzer tippt weiter rm, und das Netz haengt trotzdem darunter, selbst wenn die Loeschung drei Prozesse tief in einem Build-Werkzeug passiert, wo kein Alias hinreicht.

Der Unterschied zu Snapshots liegt in der Granularitaet: undo arbeitet befehlsgenau, nicht zeitgenau. Ein Snapshot rollt den gesamten Verzeichnisbaum auf einen Zeitpunkt zurueck und reisst dabei die zwischenzeitliche gute Arbeit mit. undo nimmt genau das zurueck, was dieser eine Befehl beruehrt hat, auf jedem Dateisystem und ohne root. Die Metadaten zeigen ein kleines, fokussiertes Projekt: 385 Sterne, 13 Forks, 8 offene Issues, geschrieben in Go, lizenziert unter MIT.

Der Mechanismus von libundo.so: abgefangene libc-Aufrufe und ein Journal pro Befehl

Es gibt keinen Daemon und nichts laeuft zwischen den Befehlen. Ein Shell-Hook fuer zsh, bash oder fish aktiviert um jeden Befehl eine kleine LD_PRELOAD-Bibliothek namens libundo.so. Solange sie aktiv ist, fängt die Bibliothek zerstoererische libc-Aufrufe ab, etwa unlink, rename, open mit Schreib-Flags, rmdir, mkdir und chmod. Bevor ein Aufruf durchgeht, sichert sie die betroffene Datei in einer pro Befehl angelegten Session und haengt eine Zeile an ein Journal an.

Loeschungen werden per Hardlink gesichert, sodass rm -rf ueber mehrere Gigabytes keine Daten kopiert und kaum Kosten verursacht. Zur Wiederherstellung liest undo das Journal der letzten Session und spielt es rueckwaerts ab: geloeschte Dateien werden neu verlinkt, Umbenennungen zurueckgeschoben, gekuerzte Dateien gegen ihre Sicherungen getauscht, versehentlich erzeugte Dateien entfernt und Verzeichnisse mit ihren urspruenglichen Modi neu angelegt. undo redo setzt eine zurueckgenommene Session wieder ein, eine Session laesst sich beliebig oft zwischen zurueckgenommen und angewendet umschalten.

Session-Speicher und Budget: Das Format unter ~/.local/share/undo/sessions

Jeder Befehl, der etwas veraendert hat, bekommt ein Session-Verzeichnis unter ~/.local/share/undo/sessions, angelegt mit Modus 0700. Das Format sind schlichte Dateien zum Nachlesen: cmd haelt die Befehlszeile fuer undo list, journal enthaelt eine Zeile pro Aenderung, pid- und done-Markierungen verhindern, dass undo einen laufenden Befehl anfasst, und budget zaehlt die gespeicherten Bytes der Session. Unter data liegen die Sicherungen als Hardlinks.

Der Speicher behaelt die letzten 30 Sessions innerhalb eines Budgets von 1 GiB, beides ist konfigurierbar; undo purge leert den Speicher vollstaendig. Die juengste Session bleibt immer erhalten, selbst wenn sie allein das Budget ueberschreitet, denn genau sie ist das Ziel des naechsten undo. Befehle, die nichts veraendern, hinterlassen keine Session. Beim Ueberschreiben von Dateien an Ort und Stelle faellt dagegen Speicherplatz an, weil ein Hardlink den gleich neu geschriebenen Inhalt nicht bewahren kann; die Voreinstellung begrenzt pro Datei 256 MiB, steuerbar ueber UNDO_MAX_BYTES.

Installation von undo: install.sh, Homebrew, deb- und rpm-Pakete sowie die Hook-Zeilen

Der einfachste Weg ist ein Einzeiler ohne root: curl -fsSL https://undo.edaywalid.com/install.sh | sh installiert nach ~/.local und fragt danach, ob die Hook-Zeile in die Shell-rc eingetragen werden soll, wobei die genaue Zeile vorher angezeigt wird. In Umgebungen ohne Terminal, etwa in CI oder bei einer gepipten Installation, wird nichts veraendert; UNDO_MODIFY_RC=1 beziehungsweise UNDO_NO_MODIFY_RC=1 beantworten die Frage vorgezogen fuer Skripte.

Alternativ bietet das Projekt Pakete: brew install edaywalid/tap/undo fuer Homebrew unter Linux, .deb- und .rpm-Dateien aus den Releases fuer Debian, Ubuntu, Fedora und openSUSE, das AUR-Paket undo-cli-bin fuer Arch sowie nix run github:edaywalid/undo. Aus dem Quelltext entsteht die Fassung mit make install, wozu gcc und go noetig sind. Die Hook-Zeilen heissen etwa source /usr/share/undo/undo.zsh fuer zsh, undo.bash fuer bash 5 oder neuer und undo.fish fuer fish 3.4 oder neuer; je nach Installationskanal liegt das Hook-Verzeichnis bei /usr/share/undo/, unter ~/.local/share/undo/ oder im brew-Prefix. Nach der Aktivierung verifiziert undo doctor die Installation und loescht und stellt zur Probe eine Kanariendatei wieder her.

Der Befehlsumfang: undo, undo diff, undo -i und undo run

Der Hauptbefehl ist schlicht undo auf eigener Zeile: Er nimmt den letzten Befehl zurueck, der Dateien veraendert hat. Das README warnt ausdruecklich davor, undo mit && zu verketten, denn eine verkettete Zeile ist fuer die Shell ein einziger Befehl, und undo liefe dann innerhalb genau der Session, die es rueckgaengig machen soll, noch bevor jener Befehl beendet ist. Aus demselben Grund gehoert der Prueflauf touch x, rm x, undo auf drei eigene Zeilen.

Dazu kommen Ergaenzungen fuer den Alltag: undo -i waehlt eine Session aus und erlaubt das cherry-picking einzelner Eintraege, undo diff zeigt Inhaltsdifferenzen einer Session, undo list und undo show liefern Uebersichten, undo apply nimmt eine bestimmte Session per Kennung zurueck. Ohne Hook, etwa fuer ein einzelnes zweifelhaftes Skript, bewaffnet undo run -- ./sketchy-cleanup.sh genau diesen einen Aufruf ohne jede Einrichtung. undo gc und undo purge pflegen den Speicher, undo upgrade und undo uninstall behandeln Aktualisierung und Entfernung.

Grenzen des Schutzes: statische Binaries, sudo, macOS und die Backup-Warnung

Weil LD_PRELOAD nur dynamisch gelinkte Programme erreicht, die ueber libc laufen, sieht undo einiges nicht: statische Binaries und Programme mit rohen Syscalls, sudo- und setuid-Prozesse, Schreibvorgaenge ueber vor der Session geoeffnete Deskriptoren, mmap-Schreibvorgaenge sowie chown und Metadaten jenseits der Modusbits. Alles, was ausserhalb der gehookten Shell laeuft, bleibt unsichtbar, solange man nicht undo run verwendet. Das README fasst es in einem klaren Satz zusammen: Dies ist ein Sicherheitsnetz, kein Backup.

Die Plattformunterstuetzung ist ebenfalls eingegrenzt: Vorgesehen sind Linux auf amd64 und arm64 mit glibc, einschliesslich WSL2; unter Alpine mit musl hilft ein Build aus dem Quelltext. macOS wird nicht unterstuetzt, weil SIP die Bibliotheksinjektion blockiert, und Snap- sowie Flatpak-Umgebungen sind architektonisch ausgeschlossen. Die Konfiguration laeuft ueber Umgebungsvariablen wie UNDO_KEEP, UNDO_MAX_STORE, UNDO_DATA_DIR und UNDO_IGNORE, die vor dem Laden des Hooks gesetzt werden. Die Releases v0.2.8, v0.2.9 und v0.3.0 vom Juli und August 2026 zeigen einen kurzen, dichten Entwicklungszeitraum.

Redaktionelles Fazit

undo passt fuer Linux-Nutzer, die ein Sicherheitsnetz fuer rm-, mv- und chmod-Ausrutscher wollen, ohne ihre Gewohnheiten zu aendern oder Snapshots einzurichten. Wer unter macOS, mit statischen Binaries oder mit sudo-Befehlen arbeitet, bleibt vom Schutz ausgeschlossen; ein Backup ersetzt das Werkzeug nach eigener Aussage nicht.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes