OK, ich habe fast ein Jahrzehnt lang auf verschiedenen Ebenen als Systemadministrator gearbeitet und bin dennoch einem uralten Fehler zum Opfer gefallen, obwohl ich nicht verstehe, warum das passiert ist.
Ich war auf meinem Server und habe fast 15 Jahre alte .tar.gz-Dateien durchgesehen, sie dekomprimiert und dann die Daten durchgesehen. Ich habe sogar immer einen neuen Ordner als Sandbox verwendet. Ich war in einem Ordner ( /DATA/RAID1/ROOT/SORTME/BACKOPEN), der ein unkomprimiertes Archiv einer früheren Ubuntu-Installation enthielt, als ich beschloss, die offensichtlicheren Systemordner zu entfernen, von denen ich wusste, dass ich sie nicht brauchen würde. Als ich meinen ausführte, rmlief er bis zum Ende, aber als er fertig war, hatte ich keine /bin, /sbin, oder einen der anderen mit dem Stamm verknüpften Ordner mit Namen wie die, die ich zu entfernen versuchte.
Der anstößige Befehl:
root@dev1:/DATA/RAID1/ROOT/SORTME/BACKOPEN# rm -rfv cdrom/ boot/ bin/ calpp/ dev/ etc/ ldconfig icd-registration.tgz lib/ lib32/ lib64/ opt/ sbin/ selinux/ share/ srv/ usr/ var/
Jetzt ist mir im Nachhinein klar, dass ich diese Verzeichnisse schon vorher hätte haben MÜSSEN, ./um den relativen Pfad zu berücksichtigen, aber ich bin immer noch verwirrt, warum /binoder /sbinob sie entfernt würden, wenn ich sie ausdrücklich angegeben hatte bin/ sbin/und zu diesem Zeitpunkt NICHT drin war /.
Mir scheint, wenn ich mit meinem Passwort gearbeitet hätte und keinen vorangestellten Schrägstrich zur Angabe des Root-Benutzers gehabt hätte, hätten nur die Verzeichnisse in dem Verzeichnis gelöscht werden sollen, in dem ich mich befand.
Gott sei Dank hatte ich weder einen einzigen /noch einen der Namen meiner ZFS-Pools darin, rmund so ist alles in Ordnung, aber ich würde diesen Fehler sehr gern nie wieder machen.
Die Vorstellung, ein Betriebssystem auf diese Weise zu verpfuschen, ist peinlich und ich kann nicht anders, als zu denken, dass etwas anderes ./die Lösung wäre.
Was übersehe ich hier?
Vielen Dank im Voraus für Ihre Bemühungen.
AKTUALISIEREN:
OK, also bin ich nach Hause gekommen und habe 14.04 von genau demselben ISO neu installiert, das ich seit der Veröffentlichung verwende. Ich habe meine ZFS-Pools (/DATA/RAID1|/DATA/RAID2) erneut importiert und /DATA/RAID1/ROOT/SORTME/BACKOPEN überprüft, nur um festzustellen, dass ALLE Verzeichnisse/Dateien, die ich im fehlerhaften Befehl angegeben hatte, noch vorhanden waren. Da ich mich nicht selbst in Schwierigkeiten bringen wollte, habe ich den fehlerhaften Befehl in meinen Beitrag kopiert und eingefügt, ABER jedem Pfad-/Dateiargument ein ./ vorangestellt. ES HAT FUNKTIONIERT und mein Betriebssystem NICHT verpfuscht. Ich habe auch die Ausgabe von rm -rfv in eine Datei umgeleitet, um sie später zu untersuchen. Kein Teil meines Betriebssystems wurde entfernt, alles war gut. Ich vermute, wenn harte oder symbolische Links das Problem gewesen wären, hätte ich dasselbe Problem gehabt, aber dieses Mal war es nicht der Fall. Die Handlung verdichtet sich. Ich habe das Gefühl, dass ich vielleicht nie eine Antwort bekommen werde, aber es scheint, als wäre dies vielleicht nur eines dieser Dinge, die durch einen verrückten Zufall passiert sind. Ich kann mit Sicherheit sagen, dass ich in Zukunft viel vorsichtiger sein werde ...