Diskussion:Rm (Unix)

Einmaliges Überschreiben doch sicher?

Laut Artikel ist es nach einmaligem Überschreiben oft noch möglich Daten zu rekonstruieren, wofür es allerdings keine Quellen gab. Laut Heise ist dem anders: [1]

Bevor ich den Hinweis einfüge, dass einfaches löschen genügt, würde ich jedoch noch gerne die Gelegenheit geben, anderslautende Quellen zu nennen.

Gruß, --Dr. Al. K. Lisch ?!  +/- 19:39, 2. Feb. 2010 (CET)

Durch die Technik der Flash-Speicher hat sich das Sicherheitsproblem etwas verschärft, näheres z.B. hier BSI: Daten endgültig löschen. Soll das mit eingebaut werden? 217.91.63.146 10:50, 11. Mär. 2024 (CET)

rm und unlink?

Und was ist daran jetzt besonders, oder Unix-Spezifisch? DEL verhält sich unter Windows nicht anders, wenn mehrere Links zur Datei existieren. --Bachsau 14:07, 5. Aug. 2011 (CEST)

Unter UNIX findet ein richtiger unlink() statt. Die inode-List und der Superknoten werden nachhaltig verändert, sodaß der Fileinhalt mit normalen Mitteln nicht mehr zu rekonstruieren ist, selbst, wenn die Diskblocks noch nicht überschrieben wurden. MS-DOS-artige Filesysteme hingegen speichern die Blocks, die ein File belegt, in der FAT als vorwärtsverkettete Liste ab und löschen nur den ersten Eintrag dieser Liste, sowie im Directory den ersten Buchstaben des Filenamens. Daraus kann man das Gesamtfile relativ leicht rekonstruieren, was die ganzen undelete-Programme ja auch vorzeigen. --bakunin (Diskussion) 11:37, 12. Nov. 2015 (CET)

unlink ist nicht gleich unlink. Nicht jede unlink-Implementierung nutzt den unlink()-Systemaufruf. LG, ℳ웃79 ^✍ 17:11, 8. Jun. 2016 (CEST)

Rekursiv Dateien/Verzeichnisse mit bestimmten Namen löschen

Alle Dateien (-type f .. 'file') im aktuellen Verzeichnis ('.') sowie allen Unterverzeichnissen finden, die *.o heißen, und sie dann weglöschen:

find . -type f -name *.o -exec rm {} \;

Selbiges für Verzeichnisse namens '.svn':

find . -type d -name ".svn" -exec rm -Rf {} \;

Nur als nützliche Anmerkung... --arilou (Diskussion) 13:39, 4. Jul. 2014 (CEST)

Das ist keine "nützliche Anmerkung", sondern falsch. Da nämlich in der Zeile

find . -type f -name *.o -exec rm {} \;

der Fileglob nicht gequotet ist, wird der schon vor der Ausführung von find expandiert. So wie es geschrieben ist, funktioniert es ausschließlich dann, wenn in dem aktuellen Directory (".") keine einzige Datei mit Endung "o" steht, weil nur dann der Asterisk literal weitergegeben wird. Richtig muß das so aussehen:

find . -type f -name "*.o" -exec rm {} \;

--bakunin (Diskussion) 11:31, 15. Nov. 2015 (CET)

Danke! --arilou (Diskussion) 12:05, 18. Nov. 2015 (CET)

rm -rf

Die Einlassung

Führt man dieses Kommando als Administrator (root) aus, führt das prinzipiell zur unwiderruflichen Löschung des gesamten Systems;

ist zwar konzeptionell nachvollziehbar, aber trotzdem falsch: richtig ist, daß auf real existierenden Systemen der rm-Prozess irgendwann die libc unlink()-ed und danach üblicherweise mit einer Fehlermeldung abbricht. Danach hat man zwar ein unbrauchbares, aber nicht unbedingt gesamt gelöschtes System. Wie man [etwa hier] in epischer Breite referiert sehen kann. --bakunin (Diskussion) 11:28, 12. Nov. 2015 (CET)

Ich müsste das mal ausprobieren, aber: Wenn rm bereits (inkl. benötigter Bibliotheken) im Ram ist, sollte es eigentlich problemlos weiterlaufen, auch wenn es sich selbst (auf der Platte), die Bibliotheken (auf der Platte) und was-auch-sonst-noch-alles bereits gekillt hat. Selbst /dev sollte kein Problem sein, solange die notwendigen Handles im Ram geöffnet sind und die notwendigen Treiber (im Ram) geladen sind.

In deinem aufgeführten Link wird übrigens geschrieben, dass das rm-Kommando vom (Root-)Benutzer abgebrochen wurde. ("fortunately Neil had interrupted rm while...")

--arilou (Diskussion) 13:01, 18. Nov. 2015 (CET)

Ich habs mal auf ein paar Systemen ausprobiert: AIX und SunOS verhalten sich so wie von mir beschrieben: irgendwann wird der Löschprozess abgebrochen, das System ist zwar unbrauchbar und bootet auch nicht mehr, aber wenn man die Reste des Filesystems mountet, dann finden sich noch ein paar Dateien, meistens in /var (vielleicht, aber das ist nur eine Vermutung, weil "var" nach "usr" im Alphabet kommt und irgendwann bei der Löschung von "/usr" das Kommando abbricht). Fedora 21 und Ubuntu 14 sind ähnlich, allerdings sind bei mehreren Versuchen immer andere Dateien stehengeblieben. Das Ubuntu hats einmal tatsächlich geschafft, die Platte komplett zu putzen.

Was passiert, wenn man das auf einem tatäschlich benutzten System macht, wo die Shared Libraries schon im Cache stehen, kann ich nicht beurteilen. Die Systeme für meine Versuche waren frisch aufgesetzt. --bakunin (Diskussion) 01:24, 14. Dez. 2015 (CET)

Vielen Dank für die Eindeutschung

Mittlerweile findet sich - neben vielerlei Halbrichtigem - auch endlich dieses final eingedeutschte Kleinod:

Dateien bei Unix- und abgeleiteten Dateisystemen bestehen aus dem eigentlichen Datenbestand (z. B. Dateiinhalte), dem Datenobjekt, das einem eindeutigen Datenknoten, dem Inode, zuordnet ist, einerseits und andererseits aus mindestens einem Verweis (engl. ‚link‘) auf jenen Inode, der als „voller“ Dateiname (inkl. Pfad) repräsentiert wird. Ein Inode kann dabei mehrere Dateinamen, also Dateiobjektverweise (‚hard links‘), haben.

Während ich noch auf die Aufklärung darüber warte, was an "Datenbestand" denn sonst noch, außer dem "als Beispiel" angeführten Dateiinhalt, so alles gemeint sein könnte, habe ich mir die Mühe gemacht und auch diese ganzen scheußlichen restlichen Fremdworte gegen gute deutsche Ausdrücke getauscht. Mein Vorschlag zur Neuformulierung des zitierten Absatzes:

Sachverhaltsansammlungen bei Unix- und abgeleiteten Sachverhaltsansammlungsanordnungen bestehen aus dem eigentlichen Sachverhaltsansammlungsbestand (zB. Sachverhaltsansammlungsinhalte), den Sachverhaltsansammlungsgegenstand, das einem eindeutigen Sachverhaltsansammlungsknoten, dem I-Knoten, zugeordnet ist, einerseits und andererseits aus mindestens einem Verweis auf jenen I-Knoten, der als "voller" Sachverhaltsansammlungsname (miteingeschlossen Pfad) vergegenständlicht wird. Ein I-Knoten kann dabei mehrere Sachverhaltsansammlungsnamen, also Sachverhaltsansammlungsgegenstandsverweise (harte Verbindungen) haben.

Ich frage mich, ob man nicht noch darauf hinweisen sollte, daß es neben harten Verbindungen auch weiche Verbindungen gibt, bei manchen Verbindungen die größere und die kleinere Nummer wichtig ist und manche Dateianordnungen über einen folgerichtigen Rauminhaltsvorgesetzten gesteuert werden. --bakunin (Diskussion) 20:04, 5. Jun. 2016 (CEST)

Hallo, ich wollte mit »z. B. Dateiinhalte« dem Umstand gerecht werden, dass es nicht nur regular files gibt. Ich denke, jetzt ist das besser.

Dein Vorschlag wirkt auf mich eher, als sei das ein Scherz deinerseits. Ich habe keine Übersetzung vorgenommen, ich habe einen unpräzisen, irreführenden, unverständlichen Text durch einen erklärenden ersetzt. (Oh, ich habe oben die Sig. vergessen) LG, ℳ웃79 ^✍ 17:11, 8. Jun. 2016 (CEST)

Nein, das war leider kein Scherz, nur etwas sarkastisch formuliert.

Vielleicht kommt es ja nur mir so vor, aber bei der Formulierung dem eigentlichen Datenbestand (z. B. Dateiinhalte) frage ich mich, was denn noch andere Datenbestände außer Dateiinhalten sein könnten. Wenn man irgendwas "beispielhaft" anführt, dann setzt das voraus, daß es andere, nicht angeführte Alternativen gibt: ich kann dir eine natürliche Zahl, "beispielsweise 1", nennen, aber nicht "irgendeine natürliche Zahl kleiner 2, beispielsweise 1".

Was mir außerdem so sehr mißfällt, daß ich mittlwerweile keine Lust mehr habe, an Artikeln überhaupt noch zu schreiben, das ist diese Manie, Fachbegriffe (und zwar, soweit ich das beurteilen kann, lediglich in der IT) in irgendwelchen verdeutschten Humbug zu übersetzen. Den Medizinern würde es nicht im Traum einfallen, die "Schulterluxation" als Weiterleitung zum Lemma "Schulterumrichtung" (das nämlich bedeutet "Luxation") einzuordnen, aber in der IT wird etwa das "device" - nur weil man nicht richtig Englisch kann und auch sonst keine Ahnung von der Materie hat - als "Gerät" übersetzt. Und wenn sich herausstellt, daß das spezielle device gar kein "Gerät" ist - na, dann ist es wohl ein "virtuelles Gerät" oder ein "virtuelles Pseudogerät". Vielleicht ist es ja auch gar kein Gerät, sondern eine "Methode", ein "Kunstgriff" oder ein "Verfahren" (alles mögliche Übersetzungen des Wortes "device"), aber dazu müßte man sowohl erstens Englisch können und zweitens wissen, wovon eigentlich die Rede ist.

Im vorliegenden Fall ging es nicht um ein device, sondern den "Datenknoten". Was soll das sein? Und warum darf das Ding nicht "Inode" heißen? Ich halte mich für einen passablen Kenner der Materie, aber den "Dateiobjektverweis" hätte ich nicht als hard link erkannt. Wem soll der Artikel eigentlich nützen, wenn schon UNIX-Systemadministratoren mit 30 Jahren Berufserfahrung nicht verstehen, wovon die Rede ist?

Klar, wir reden hier deutsch. Ich für meinen Teil meine, daß das beste Deutsch aus lauter Fremdwörtern zusammengesetzt sein kann: ich gehe morgens ins Büro (nicht an die Arbeitsstätte), verwende einen Computer (keinen Berechner) und wenn ich Sourcecode (keinen Ursprungstext) übersetzen will, dann verwende ich einen Compiler und für das Object dann einen Linker (ich vermute mal stark, daß Leute, die von "relokatiblem Code" und "Bindern" sprechen, beide noch nie aus der Nähe gesehen geschweige denn professionell eingesetzt haben). Aber wenn das nicht so ist und wir schon die Sprache unbedingt "reinigen" müssen - dann sollten wir konsequenterweise auch die ganzen lateinischen, griechischen und sonstigen Fremdwörter aus unserem - sorry, beinahe hätte ich "Jargon" gesagt - unserer Wortgebrauchsweise entfernen und dann gibt es eben keine Files, aber auch keine Dateien ("datum" ist Latein), sondern nur noch Sachverhaltsansammlungen, die in Sachverhaltsansammlungsanordnungen ("filesystems") zusammengefaßt sind. Die in Unix übliche Major Number und Minor Number wird dann zur (allgemein verständlichen) größeren Nummer und kleineren Nummer und der Logical Volume Manager zum "folgerichtigen Rauminhaltsvorgesetzten". ---bakunin (Diskussion) 21:04, 14. Jun. 2016 (CEST)

Ich kann und will nicht auf allem im Detail eingehen …

Ich verstehe gut was Du meinst. Mit dem ganzen Übersetzungswahn hast Du sehr recht. Allerdings, schau Dir bitte genau den Wortlaut an. Dort steht z.B. Datenobjekt, nicht Dateiobjekt (letztes ergibt keinen Sinn). Dort steht auch nicht, dass ein Inode (schreckliche Eindeutschung übrigens) als Datenknoten bezeichnet wird, sondern dass das Inode ein Datenknoten ist – genauer – dass es einen Datenknoten gibt und dieser als Inode bezeichnet wird. (Ein Dateiname verweist nicht auf die eigentlichen Daten, sondern auf den Inode und der verweist auf die eigentlichen Daten; nur deshalb sind mehrere Hard-Links möglich.)

Bitte beachte, dass in der WP nunmal allgemein verständliche Begriffe benutzt werden müssen und lediglich zusätzlich Umgangssprache erwähnt wird. Leider decken sich im Deutschen selten Lehrbuch-Fachsprache und tatsächlich benutzte Fachsprache (wer nutzt schon „Umschalttaste“?)

Geanu dies ist ja das Problem! Wenn die benutzten Begriffe eben nicht "allgemein verständlich" sind, sondern nicht mal dem Experten geläufig, dann ist dieser künstliche Jargon eben nicht mehr "allgemein verständlich", sondern: Humbug! (Um es mit einem Fachbegriff zu bezeichnen: Bullshit!) --17:57, 14. Jul. 2016 (CEST)

Dateien sind – nochmals – keine Sachverhaltsansammlungen (wenn überhaupt wären sie Sachverhaltseansammlungen), sie „beinhalten“ keine Sachverhalte sondern 1en und 0en – alles andere ist Interpretation dieser 1en und 0en.

Seufz. Ja. Das ist mir schon klar und der vorgeschlagene Begriff war ja auch nicht ernst gemeint. Aber entweder wir einigen uns darauf, daß wir eben Fremdwörter verwenden oder darauf, daß wir das unterlassen. Dieses selektive Herausfiltern von Anglizismen bei gleichzeitiger Beibehaltung von Gräzismen, Latinismen und anderem Althergebrachten ist jedenfalls inkonsequent (nichtdurchhaltend). Man kann sichs nun mal nicht aussuchen und entweder wir reden von "files" und "devices", weil sich die - aus dem Englischen kommende - Fachsprache dieser Begriffe nun mal bedient, analog zu den Medizinern, die dasselbe mit lateinischen und griechischen Begriffen betreiben, oder wir deutschen das alles auf Fremdwort komm raus ein. Dann darf aber auch von lateinischen und griechischen (und am besten von germanischen auch) Wurzeln nichts mehr übrig bleiben und wir werden uns an die EDV-Äquivalente des "Vier-Topf-Vier-Bumms-Zerknall-Treiblings" (4-Zylinder-Ottomotor) gewöhnen müssen. (nicht signierter Beitrag von Bakunin (Diskussion | Beiträge) 18:03, 14. Jul 2016 (CEST))

Übrigens, wenn im Deutschen von „Device“ geredet wird, meint man damit – anders als im Englischen – nicht das reale, physisch vorhandene Gerät, sondern die Schnittstelle mit der das reale, physisch vorhandene Gerät angesprochen wird.

Man meint schon das Gleiche, nur nennt man es anders. Denn wahlweise ist bei einem "device" von einem physischen Gerät, einem Satz Systemcalls ("Anordnungsaufrufen") mit einer fixen Lokation im Filesystem als Access Point oder auch von was ganz anderem die Rede. Alles das wird durch die Bedeutung des Wortes "device" im Englischen abgedeckt und durch die Bedeutung des Wortes "Gerät" in Deutschen nicht. /dev/random etwa ist überhaupt kein "Gerät", weder ein physisches, noch sonst eines (auch kein "virtuelles"), genauso wie /dev/null. Es ist aber sehr wohl ein "device", nämlich ein (UNIX-typischer) Kunstgriff, wie man einen bestimmten Service über eine fixe Stelle im Filesystem ansprechen kann. Wenn wir gleich das richtige "device" verwenden würden, dann müßten wir nicht die (siehe die Diskussionsseiten zu den genannten "Geräten") schwachsinnige Unterscheidung in "Geräte, die Geräte sind" und "Geräte, die eigentlich gar keine Geräte sind, aber die wir trotzdem so nennen, damit wir uns ein Fremdwort vom Mund absparen" schenken. Denn die Logik "ich nenne eine Rasenmäher Kinderwagen - und wenns kein Kinderwagen ist, dann eben 'virtueller Kinderwagen'", die will mir nicht einleuchten.

Aber, siehe eingangs, das sollen sich andere mit plankton314 ausmachen, ich habe daran das Interesse verloren. --17:57, 14. Jul. 2016 (CEST) (ohne Benutzername signierter Beitrag von Bakunin (Diskussion | Beiträge))

Mich nervt WP auch. LG, ℳ웃79 ^✍ 20:32, 16. Jun. 2016 (CEST)