Unter Linux werden wie in jedem Betriebssystem immer wieder Dateien und Verzeichnisse gelöscht. Normalerweise treten dabei keine Probleme auf. Es gibt aber einige Besonderheiten, über die sich ein Anwender im Klaren sein sollte. Einige Problemfälle und mögliche Lösungen werden hier kurz vorgestellt.

Löschen von Dateien mit rm

Der üblicherweise auf der Shell eingesetzte Befehl zum Löschen von Dateien heißt rm (remove file) und gehört zu den GNU file utilities. Sein Einsatz ist unproblematisch und bewirkt, dass der im Argument übergebene Name aus dem übergeordneten Verzeichniskatalog ohne weiteren Kommentar entfernt wird.

$> rm file

Damit löscht rm zwar die Zugriffsmöglichkeit auf die Datei, aber nicht deren Datenblöcke. Wenn für die Zieldatei keine Schreibrechte vereinbart sind (das w-Attribut also fehlt), fragt der Befehl nach, ob die schreibgeschützte Datei wirklich entfernt werden soll:

$> rm file
rm: schreibgeschützte Datei <C>file<C> entfernen?

y gefolgt von RETURN veranlasst rm, den Versuch zu unternehmen, diese Datei zu löschen. Ein solcher Versuch muss aber nicht unbedingt von Erfolg gekrönt sein. Wenn für das Verzeichnis, in dem die Datei vorhanden ist, kein Schreibrecht gesetzt wurde, kann der Dateieintrag auch nicht entfernt werden. Folglich bleibt die Datei erhalten. Der rm-Befehl verfügt über einige nützliche Optionen: Mit -i (oder --interactive) wird rm in einen interaktiven Modus versetzt. In diesem Modus muss das Löschen jeder Datei wie oben gezeigt bestätigt werden, bevor sie aus dem Verzeichnis gelöscht wird. Für Linux-Einsteiger kann es sinnvoll sein, wenn diese Option bei dem Aufruf von rm voreingestellt ist, etwa durch folgende Definition in der Datei $HOME/.bashrc:

$> alias rm='rm -i'

-f (oder --force) wirken wie eine Umkehrung zum interaktiven Modus. Diese Optionen erzwingen das Löschen, wobei die Nachfrage unterdrückt wird. Verzeichnisse können mit rm nur zusammen mit der Option -r (oder -R bzw. --recursive) gelöscht werden.

$> rm -riv dir
rm: in Verzeichnis "dir" absteigen? y RETURN
entfernen aller Einträge in Verzeichnis dir
rm: "dir/file" entfernen?  y RETURN
removing dir/file  y RETURN
Entfernen des Verzeichnises selbst: dir

In diesem Beispiel löscht rm zunächst den Inhalt des Verzeichnisses, anschließend – wenn es leer ist, und nur dann – das Verzeichnis. Die Option -v (oder --verbose) veranlasst rm, alle Aktionen zu kommentieren. Probleme beim Löschen treten beispielsweise dann auf, wenn der Name der zu löschenden Datei mit einem Minuszeichen beginnt:

$> rm -del
rm: Ungültige Option -- "e"
Versuchen Sie "rm --help" für weitere
Informationen.

In diesem Beispiel hat rmden Dateinamen als Option interpretiert. Was ist in so einem Fall zu tun? Eine einfache Lösung für derartige Probleme mit GNU-Befehlen bietet die Spezialoption --. Sie bewirkt, dass alle in der Befehlszeile rechts von ihr stehenden Teile nicht mehr als Optionen, sondern als Textargumente interpretiert werden.

$> rm -- -del

Zeichen, die von der Shell selbst ausgewertet werden (Metazeichen), müssen immer maskiert werden, wenn sie in Dateinamen auftreten:

$> rm file#1*

Mit dieser Befehlszeile versucht rm, Dateien zu entfernen, deren Namen mit den Buchstaben file#1 beginnen. (Das Sternchen ist ein Wildcard-Zeichen und steht für beliebige Zeichenketten.)

$> rm 'file#1*'

So wird eine Datei mit dem Namen file#1* gelöscht. Alternativ könnte auch ein Backslash vor die Metazeichen im Dateinamen gesetzt werden. Entsprechendes gilt übrigens auch für Leerzeichen in Dateinamen:

$> rm file#1\*
$> rm Dateiname\ mit\ Leerzeichen

Sicheres Löschen

Mit rm können zwar Dateien aus dem Dateisystem entfernt werden, aber die Datenblöcke der Dateien bleiben dabei völlig unberührt, zumindest solange, bis eine neue Datei diese Blöcke wieder belegt. Diese Tatsache machen wir uns weiter unten noch zunutze. Bei sensiblen Daten kann dieser Mechanismus unzureichend sein, da prinzipiell die Möglichkeit besteht, Daten aus gelöschten Dateien zurückzugewinnen. Daher muss also eine Möglichkeit gefunden werden, die Datenblöcke vor dem Löschen mit “Datenmüll” zu überschreiben. Danach erst wird eine entsprechende Datei aus dem Dateisystem gelöscht. Eine einfache Lösung für dieses Problem bietet folgendes Script an:

#! /bin/sh
for file in $@
do
  size=`find "$file" -printf "%k"` || continue
  dd if=/dev/urandom of="$file" bs=1k count=$size
  rm -- "$file"
done

Noch viel einfacher geht es aber mit dem Befehl wipe. Dieser verfügt analog zu rm über einen mit -i aktivierbaren interaktiven Modus, durch -f kann das Löschen erzwungen werden, und mit -r oder -R ist die rekursive Bearbeitung von Verzeichnissen möglich. Die man-Page beschreibt die zahlreichen weiteren Optionen.

$> wipe -iv del
wipe: destroy 'del'? y  RETURN

Undelete (Restauration gelöschter Dateien)

Problematisch ist es unter Linux, wenn Dateien versehentlich gelöscht wurden. Es gibt zwar eine ganze Reihe von Vorsichtsmaßnahmen, etwa das von einigen Tools verwendete Löschen durch Verschieben in ein Trash-Verzeichnis – auf der Shell ist der Anwender aber in jeden Fall gezwungen, selbst Sorge für die Sicherheit seiner Dateien zu tragen. Für das Linux-Standard- (ext2-) Dateisystem besteht die Möglichkeit, die Datenblöcke gelöschter Dateien zu retten, sofern sie noch nicht von einer anderen Datei überschrieben wurden. Als erstes sollte daher immer das betroffene Dateisystem mittels umount unmounted werden, um weitere Zugriffe zu verhindern. Die Barfuß-Methode zum Restaurieren gelöschter Dateien wird im HOWTO Ext2fs-Undeletion beschrieben. Das dort vorgestellte Verfahren basiert auf dem Einsatz der ext2-Low Level Tools debugfs und dem darauf aufbauenden e2recover-Befehl. Auch verweist der Autor des HOWTOs auf den Linux Disk Editorlde, mit dem ähnliche Aktionen durchgeführt werden können. Dieser ist in der aktuellen Version 2.5 sehr umfangreich, so dass wir ihn hier nicht berücksichtigen.

e2recover

e2recover ist ein PERL-Script, mit dem aufbauend auf einer Liste von gelöschten Inodes (die durch debugfs mit der Option lsdel erzeugt wurde) versucht werden kann, gelöschte Files zu restaurieren. Typischerweise werden die Befehle wie folgt eingesetzt:

#> DEV=/dev/hda2 ; umount $DEV
#> echo lsdel | debugfs $DEV > lsdel.out
#> e2recover -g -d$DEV lsdel.out

Zunächst wird das Dateisystem, auf dem die gelöschten Dateien vorhanden waren, in der Variablen DEV angegeben. Mittels debugfs wird eine Liste aller gelöschten Inodes dieses Dateisystems erstellt und in der Datei lsdel.out gespeichert. Andere Programmversionen dieses Befehls verwenden eine etwas modifizierte Syntax. In diesem Fall wird zunächst eine Liste von Befehlen für debugfs erstellt, die dann als Script übergeben wird:

#> echo >  debugfs.script open /dev/hdd3
#> echo >> debugfs.script lsdel
#> echo >> debugfs.script quit
#> debugfs -f debugfs.script > lsdel.out

Anschließend wird e2recover erneut aufgerufen. Über vier wichtige Optionen verfügt dieser Befehl: Durch -d (--device) legt der Anwender die Gerätedatei fest, auf der die Dateien gesucht werden sollen. Voreingestellt ist /dev/hda1. Mit -b oder --block-size kann dabei eine von der Voreinstellung 1 KByte abweichende Blockgröße für das Dateisystem angegeben werden. Als Verzeichnis für Zwischenspeicherungen wird normalerweise das /tmp-Verzeichnis verwendet. Problematisch ist dies, wenn es auf dem selben Dateisystem wie die gelöschten Dateien liegt. Daher kann mit -t (--tmpdir bzw. --tempdir) ein alternatives Verzeichnis (auf einem anderen Dateisystem) angegeben werden. Unter Kernel-Version 2.2.x wird die Option -g (--guess-indirects) verwendet, um die geänderte Form der Speicherung zu berücksichtigen. Im Idealfall sind die geretteten Dateien im /tmp-Verzeichnis in einem Unterverzeichnis e2rec... vorhanden. Der Anwender muss jetzt nur noch die Dateinamen anhand des Inhalts festlegen.

undelete

Eine intuitivere Möglichkeit zur Restauration gelöschter Dateien bietet das Tool undelete von Sebastian Hetze (von der Firma Lunetix). Dieses Tools wird zwar vom Autor noch explizit als Alpha-Version bezeichnet, in vielen Fällen funktioniert es aber bereits jetzt ausreichend. Es ist meines Wissens nach noch in keiner Distribution enthalten. Sie finden es auf dem Server von Lunetix (www.lunetix.de). undelete kennt in der Version 0.6 drei Optionen: Das Argument von -d (device) definiert die Gerätedatei, über die das betroffene Dateisystem angesprochen wird, mit -a (age) kann der Zeitraum in Stunden seit dem Löschen der Datei angegeben und damit die Anzahl der relevanten Inodes eingegrenzt werden. Voreingestellt ist die Berücksichtigung von Inodes, die zu in den letzten 24 Stunden gelöschten Dateien gehören. -f (force) erzwingt die Bearbeitung von Dateisystemen, die ohne diese Option nicht geöffnet werden würden, weil sie beispielsweise noch gemountet sind. Das Fenster von undelete ist in vier Bereiche unterteilt:

Abbildung 1: undelete in Aktion

Die aktuellen Aktionen des Programms werden immer in dem Statusfenster unten rechts angezeigt. Dort gibt das Programm auch Hinweise, was jetzt getan werden sollte, etwa, dass das bearbeitete Dateisystem demontiert werden sollte. Im Listenfenster werden die auf dem Dateisystem gefundenen Inodes gelöschter Dateien angezeigt, die in dem angegebenen Zeitlimit liegen. Weitergehende Informationen zu der Inode, auf die der Zeiger im Listenfenster verweist, stellt undelete im Infofenster dar. Die Namen der gelöschten Dateien und Verzeichnisse können wie oben dargestellt nicht restauriert werden. Deshalb werden sie in der Form unknown INODE angezeigt. Die Daten in den zu der Inode gehörenden Blöcken und andere umfangreichere Informationen zeigt undelete im Datenfenster an. Die Steuerung von undelete kann über eine Reihe von Tastenkürzeln erfolgen. ? veranlasst das Programm, diese im Datenfenster anzuzeigen. Innerhalb dieses Fensters gilt eine Tastensteuerung analog zum vi. Vorwärts und rückwärts Scrollen kann mit den Cursortasten erfolgen, die Tasten h, l, j und k erlauben das block- bzw. seitenweise Springen. Durch f wird der force-Modus aktiviert, und mit d kann ein neues Device geöffnet werden, a stellt ein anderes Höchstalter der gelöschten Inodes ein. Auf diese Weise kann sich der Anwender durch seine Dateisysteme “hangeln”, um möglichst viel von dem zu retten, was noch vorhanden ist.

Fazit

Wie man sieht, ist Rettung beim versehentlichen Löschen wichtiger Dateien oft möglich, erfordert aber natürlich einige Arbeit. Daher: glücklich ist der, der über aktuelle Backups verfügt. Aber das ist eine andere Geschichte.