ubuntuusers.de

DJKUhpisse schrieb:

Man wartet nach dem Start des Betriebssystems einige Minuten und startet dann ein Terminal^[1].

Warum soll man denn warten?

Es geht auch ohne Warten. Dann muss man aber dem DAU Leser komplizierte Denkprozesse zumuten, deren Beschreibung ich mir ersparen wollte und womit ich den Artikel nicht überfrachten wollte. Zwei Minuten Warten ist halt die einfachste Möglichkeit, die Grundlage der beschriebenen Erkennungsprozedur zu gewährleisten.

Die letzte Änderung von kB finde ich eher verwirrend als hilfreich.
Welchen Vorteil soll es haben, zu versuchen sich "dd = convert and copy a file" einzuprägen, wenn doch "disk dump" viel einfacher ist? Auch wenn heute die "offizielle" Benennung davon abweicht, so war doch "disk dump" zumindest historisch der richtige Begriff.

Außerdem entsteht so ein Widerspruch zwischen " dd (...) kopiert Dateien oder ausgesuchte Teile von Dateien" und "dd ignoriert Dateisysteme". (auch die Hervorhebung, Fett ./. Befehl ist uneinheitlich.)

Der Hinweis, dass dd auch konvertieren kann, ist zwar richtig, doch muss dies schon hier aufblähend erwähnt werden?

Die Sache mit dem Warten ist noch nicht geklärt. Der Grund dafür fehlt komplett, momentan ist das Voodoo.

Zu dd: Das hat eine Ein- und Ausgabedatei (input file if=). Man kann also von einer Datei in eine Datei schreiben (dd if=/etc/resolv.conf of=/tmp/test). Wenn man aber dd if=/etc/bla.conf of=/dev/sda schreibt, wird das Dateisystem auf sda ignoriert und stumpt der Inhalt der Quelldatei auf den Datenträger geschrieben - und das Dateisystem zerstört.

EDIT: "Brennen" auf USB-Sticks sollte man auch vermeiden. Es findet kein Brennvorgang statt.

DJKUhpisse schrieb:

Das hat eine Ein- und Ausgabedatei (input file if=).

Ja diese Benennung ist auch etwas verwirrend, kommt halt daher, dass in unixoiden Systemen "Alles ist eine Datei" proklamiert wird. Aber genauer hingeschaut, ist die Hauptaufgabe von dd doch, nackte Datenblöcke zu verarbeiten, und genau das sollte IMHO erst mal einleitend hervorgehoben werden, vor allem für den DAU.

Man kann also von einer Datei in eine Datei schreiben (dd if=/etc/resolv.conf of=/tmp/test).

Man "kann" das so machen, doch dafür gibt es doch eindeutig bessere dafür geeignete Befehle, z.B. cp.

EDIT: "Brennen" auf USB-Sticks sollte man auch vermeiden. Es findet kein Brennvorgang statt.

Auch auf DVDs "brennt" nichts. Es werden halt ein paar Materie-Teilchen durch Energie-Eintrag an eine andere Position transferiert, im Fall von Flash-Speichern nur winzige Elektronen.

UlfZibis schrieb:

[…] Welchen Vorteil soll es haben, zu versuchen sich "dd = convert and copy a file" einzuprägen

"convert and copy a file" ist der richtige Name für dieses Programm. Welchen Vorteil sollte es haben, einen falschen zu verwenden?

Und Du musst Dir auch den richtigen Namen nicht merken, schließlich funktioniert es ja mit der Abkürzung dd.

wenn doch "disk dump" viel einfacher ist?

"das Ding" wäre auch viel einfacher, aber genau so falsch. "disk dump" beschreibt weder seine Funktion, noch ist es der richtige Name. Diese Bezeichnung wird lediglich von einigen Leuten benutzt, die offenbar entweder von der Arbeitsweise des Programms keine Ahnung haben oder aber sich einen Spaß machen wollen.

Auch wenn heute die "offizielle" Benennung davon abweicht

Nicht nur heute, der vom Autor des Programms gewählte Name "convert and copy a file" war immer schon der einzig wahre Name des Programms.

so war doch "disk dump" zumindest historisch der richtige Begriff.

"disk dump" war nie der richtige Begriff, weder historisch noch funktional noch in irgend einem anderen Sinn.

Außerdem entsteht so ein Widerspruch zwischen " dd (...) kopiert Dateien oder ausgesuchte Teile von Dateien" und "dd ignoriert Dateisysteme".

Da Dateien unabhängig von Dateisystemen existieren können, wo ist da ein Widerspruch? dd kopiert Dateien, ignoriert aber eventuell auf Quelle bzw. Ziel bestehende Dateisysteme. Damit kann es auch da kopieren, wo noch kein Dateisystem jemals war – und es kann auch bestehende Dateisysteme zerstören, womit sein Spitzname "disk destroyer" durchaus gerechtfertigt (aber im Grunde auch falsch) ist.

(auch die Hervorhebung, Fett ./. Befehl ist uneinheitlich.)

Das stammt nicht von mir. Ich habe es nicht geändert, weil es schon vorher Wiki-konform war und auch allgemein üblich ist: Den Begriff, den man behandeln möchte, hebt man bei der ersten Erwähnung hervor – z.B. durch Fettschrift – muss das bei weiteren Erwähnungen aber nicht wiederholen.

Der Hinweis, dass dd auch konvertieren kann, ist zwar richtig, doch muss dies schon hier aufblähend erwähnt werden?

Es ist der vorgesehene Zweck dieses Programms dd und Unterscheidungsmerkmal zum anderen gängigen Kopierprogramm cp. Wann, wenn nicht in der Einleitung, sollte man es erwähnen?

DJKUhpisse schrieb:

Die Sache mit dem Warten ist noch nicht geklärt. Der Grund dafür fehlt komplett, momentan ist das Voodoo.

Für DAUs: Es geht um die Ermittlung der Gerätedatei für einen USB-Stick, auf den man eine Datei „brennen“ (Warum schreibe ich (wie frühere Bearbeiter dieses Artikels) dieses Wort wohl in Anführungszeichen?) will.

Gerätedateien werden vom Init-System systemd automatisch bei Bedarf erzeugt, d.h. beim Hochlauf des Betriebssystems und beim Einstecken des Sticks. Man wartet nun ganz einfach ab, bis die Erzeugung der Gerätedateien für allgemeine Zwecke des Betriebssystems zur Ruhe gekommen ist und steckt erst dann den Stick ein. Alle Gerätedateien, die nun – später als alle, die nichts mit dem Stick zu tun haben – angelegt wurden, müssen zum Stick gehören.

Ja. Ist Voodoo. Funktioniert aber.

UlfZibis schrieb:

[…] ist die Hauptaufgabe von dd doch, nackte Datenblöcke zu verarbeiten

Was auch immer Du unter „nackten Datenblöcken“ verstehst, das Programm dd macht ausschließlich dieses:

• Es liest aus der angegebenen Eingabedatei Records fester Länge ein. Länge eines Records und dessen Position in der Eingabedatei sowie deren Anzahl werden über Parameter spezifiziert.

• Es konvertiert eingelesene Records hinsichtlich Inhalt und Länge zu Ausgaberecords. Auch hier sind die Einzelheiten über Parameter spezifizierbar. Ein Spezialfall für eine Konversion ist die 1:1-Kopie. Oder N:M-Kopie.

• Es schreibt die Ausgaberecords in die angegebene Ausgabedatei an eine über Parameter vorgebbare Stelle relativ zum Dateianfang.

Seine Arbeitsweise könnte man also mit „konvertieren und kopieren einer Datei“ beschreiben.

Mit der Blockstruktur eines Datenträgers oder überhaupt mit Datenträgern hat das gar nichts zu tun, ausgenommen, dass die Vorgabe für die Record-Längen der bei magnetischen Festplatten früher üblichen Sektorlänge von 512 Byte entspricht; und das ist für fast alle Blockgeräte (optische Datenträger, Flash-Speicher, Dateisysteme, …) eine schlechte Wahl.

kB schrieb:

"convert and copy a file" ist der richtige Name für dieses Programm.

Das ist nicht der NAME des Programms, sondern die (Kurz-)Beschreibung seiner FUNKTION, und so sollte es IMHO auch behandelt werden.

Welchen Vorteil sollte es haben, einen falschen zu verwenden?

Da es dann offensichtlich keinen richtigen gibt außer dd, sollte man eben auch keinen weiteren verwenden.

Und Du musst Dir auch den richtigen Namen nicht merken, schließlich funktioniert es ja mit der Abkürzung dd.

Das mag für den langjährigen Nutzer so sein, der ist aber eher nicht der typische Leser dieses Artikels, der braucht den nicht mehr. Zumindest ich brauche bei mir anfangs unbekannten Kürzeln so eine Eselsbrücke, und sie erleichtert die Kommunikation mit Linux-Anfängern ungemein, wenn man mit "dd" daherkommt.

Nicht nur heute, der vom Autor des Programms gewählte Name "convert and copy a file" war immer schon der einzig wahre Name des Programms.

Ich behaupte mal, dass das eher der Autor des Manuals kreiert hat, welches ja bekanntlich üblicherweise immer erst später und oft von anderen erstellt wird. Wenn Du so gut informiert bist, weißt Du doch sicher auch, an was der Autor des Programms bei dd wirklich gedacht hat. Genau die originäre "Eselsbrücke" fehlt dann im Artikel, denn die bisher erwähnten sind ja Deiner Meinung nach falsch.

Da Dateien unabhängig von Dateisystemen existieren können,

Eine kreative aber aus meiner Sicht keine hilfreiche Definition. Ja auch Buchstaben-Folgen existieren theoretisch unabhängig vom tragenden Gerüst, also z.B. Papier. 😉
Laut Wikipedia bedingt eine Datei einen "geordneten zur Aufbewahrung geeigneten Bestand", also ein (Datei-)System. Zitat:

Dem Duden zufolge ist die Datei ein „nach zweckmäßigen Kriterien geordneter, zur Aufbewahrung geeigneter Bestand an sachlich zusammengehörenden Belegen oder anderen Dokumenten.“^[1] Das Wort „Datei“ ist ein Kunstwort aus Daten und Kartei,^[2] weil eine Kartei vergleichbar aus Karteikarten mit einheitlicher Inhaltsstruktur besteht.

Es ist der vorgesehene Zweck dieses Programms dd und Unterscheidungsmerkmal zum anderen gängigen Kopierprogramm cp.

Da unterschlägst Du aber das aus meiner Sicht viel bedeutendere Unterscheidungsmerkmal, nämlich "Datenzugriff unter Umgehung des Dateisystems".
Was den Autor des man dazu bewogen hat, "convert" an die erste Stelle zu setzen, da kann man nur spekulieren. Vielleicht war das historisch mal die Hauptmotivation für das Programm. Das ist aber heute sicher der seltenere Anwendungsfall, zumindest für Anfänger, die erstmalig das Programm nutzen, und nur deshalb sich mit der Doku befassen. Wenn die erst mal nur "convert and copy a file" lesen, kommen die eben erst mal nicht auf die dem Programm innewohnende besondere Fähigkeit, die allgemein unter "to dump" verstanden wird.

Wann, wenn nicht in der Einleitung, sollte man es erwähnen?

Ja stimmt, solange "Copy" im Hauptfokus steht, ist das schon eine gute Ergänzung. Eigentlich wollte ich betonen, dass ich dies für die einzig sinnvolle Ergänzung hielt und nur "nebenbei" bemerken, ob der Ort dafür der beste ist.

kB schrieb:

Mit der Blockstruktur eines Datenträgers oder überhaupt mit Datenträgern hat das gar nichts zu tun,

Das habe ich auch nirgendwo behauptet. Nur die Betonung auf "blockweise Verarbeitung" war gemeint, eben im Kontrast zu "Dateisystem-gestützter Verarbeitung".

Mit dd werden ja auch die Meta-Daten einer Datei (Datum, Rechte etc.) nicht kopiert, es wird also nicht wirklich die ganze Datei kopiert.

Hallo,

UlfZibis schrieb:

kB schrieb:

"convert and copy a file" ist der richtige Name für dieses Programm.

Das ist nicht der NAME des Programms, sondern die (Kurz-)Beschreibung seiner FUNKTION, und so sollte es IMHO auch behandelt werden.

Das sehe ich in dem Fall auch so. Nach der Namenslogik würde du auch "estimate file space usage" heißen....

Die Namensgebung scheint übrigens nicht geklärt, verschiedene Stelle im Internet haben unterschiedliche Aussagen, auf der deutschen Wikipediaseite https://de.wikipedia.org/wiki/Dd_(Unix) ist es ganz gut zusammengefasst.

Gruß, noisefloor

UlfZibis schrieb:

kB schrieb:

"convert and copy a file" ist der richtige Name für dieses Programm.

Das ist nicht der NAME des Programms, sondern die (Kurz-)Beschreibung seiner FUNKTION

Der Name eines Programms folgt üblicherweise seiner Funktion.

[…]

Nicht nur heute, der vom Autor des Programms gewählte Name "convert and copy a file" war immer schon der einzig wahre Name des Programms.

Ich behaupte mal, dass das eher der Autor des Manuals kreiert hat, welches ja bekanntlich üblicherweise immer erst später und oft von anderen erstellt wird.

Deine Spekulation. Und falsch.

Wenn Du so gut informiert bist, weißt Du doch sicher auch, an was der Autor des Programms bei dd wirklich gedacht hat.

Die naheliegende Abkürzung für den Programmnamen (oder Funktionsbeschreibung) "convert and copy a file" wäre cc. Und genauso sollte nach Wunsch des Autors auch der Name für das aufrufbare Programm lauten. Leider war dieser Name schon vergeben für den C-Compiler. Und deshalb hat man damals das übliche Verfahren zur Auflösung von Kollisionen bei Hash-Funktionen angewendet und einfach weiter gezählt. Aus cc wurde dd = "convert and copy a file".

kB schrieb:

DJKUhpisse schrieb:

Die Sache mit dem Warten ist noch nicht geklärt. Der Grund dafür fehlt komplett, momentan ist das Voodoo.

Für DAUs: Es geht um die Ermittlung der Gerätedatei für einen USB-Stick, auf den man eine Datei „brennen“ (Warum schreibe ich (wie frühere Bearbeiter dieses Artikels) dieses Wort wohl in Anführungszeichen?) will.

Ich würde vorschlagen, das Wort "brennen" zu vermeiden, weil es aus technischer Sicht einfach falsch ist. Besser wäre "Schreiben eines Abbildes auf einen USB-Stick".

Gerätedateien werden vom Init-System systemd automatisch bei Bedarf erzeugt, d.h. beim Hochlauf des Betriebssystems und beim Einstecken des Sticks. Man wartet nun ganz einfach ab, bis die Erzeugung der Gerätedateien für allgemeine Zwecke des Betriebssystems zur Ruhe gekommen ist und steckt erst dann den Stick ein. Alle Gerätedateien, die nun – später als alle, die nichts mit dem Stick zu tun haben – angelegt wurden, müssen zum Stick gehören.

Die entstehen innerhalb einer Sekunde, nachdem der Stick eingesteckt wurde. Es wäre mir neu, dass die sich ändern, während ein Gerät angeschlossen ist (/dev/sda bleibt /dev/sda, auch wenn weitere Geräte hinzukommen). Warum man dann warten soll, bis das zur Ruhe gekommen ist, ist mir noch unklar und ich bitte um Auskunft, da ich das noch NIE gehört habe.

Hallo,

ja, das ist eine Möglichkeit - es gibt ja noch mehr. Gut, da stimmen halt nicht mit deiner Sichtweise ein. Doof, kann aber mal vorkommen. Das Arch-Wiki behauptet z.B. was anderes Link 🇩🇪.

Aber das gute ist ja: es ist ein moderiertes Wiki und das letzte Wort hat immer das Wikiteam bzw. ein Wikimoderator. Ist halt so.

BTW: kann jemand den Titel des Threads hier korrigieren? Der ist nämlich seit Jahren falsch.

Gruß, noisefloor

noisefloor schrieb:

BTW: kann jemand den Titel des Threads hier korrigieren? Der ist nämlich seit Jahren falsch.

🤣

noisefloor schrieb:

Hallo,

ja, das ist eine Möglichkeit - es gibt ja noch mehr. Gut, da stimmen halt nicht mit deiner Sichtweise ein. Doof, kann aber mal vorkommen.

OK. Ich habe jetzt die strittige Formulierung „steht offiziell für "convert and copy a file"“ geändert in „steht lt. Dokumentation für "convert and copy a file"“.

Das Arch-Wiki behauptet z.B. was anderes Link 🇩🇪.

Die Ableitung des Namens im Arch-Wiki kenne ich, halte sie aber nicht für überzeugend, denn der Direktive „dataset definition“ in IBMs Job Control Language lautete DD (große Buchstaben) und nicht wie im Arch-Wiki behauptet dd. Das war auch 1-2 Jahrzehnte vor Erstellung des GNU-Programms dd ab 1990. Richtig ist allerdings, dass die Syntax der Aufrufparameter des Programms dd an die der Direktive DD erinnert.

Meine Sicht der Dinge wird gestützt durch die Nennung in der Dokumentation und dass ich sie seinerzeit von David MacKenzie beim Mittagessen persönlich gehört habe. Mag sein, dass er sich bereits damals einen Spaß gemacht hat und uns verulkt hat, dann ist es aber jedenfalls ein gut gelungener Ulk und stammt von einem der Autoren des Programms. Vielleicht ist es aber auch einfach die Wahrheit.

dd (steht lt. Dokumentation für "convert and copy a file" ...

1. Ich finde diese Erklärung nach wie vor mehr verwirrend denn hilfreich oder gar erklärend. Wenn schon, dann müsste auch der Übergang cc → dd erklärt werden.

2. In der Dokumentation steht auch nicht "steht für", genauso wenig wie der Doppelpunkt bei du 🇺🇸 für "steht für" steht. Insofern ist die Erklärung – bei Bezug auf die Doku – auch falsch.

3. Wenn "steht für" richtig wäre, hätte man das Programm eher ccf nennen müssen.

4. Das Programm verarbeitet nämlich zunächst auch erst mal nur Datenströme (streams). Siehe hier: "By default, dd copies standard input to standard output." Erst durch die optionale Verwendung von Operanden werden Geräte bzw. Dateien berührt.

5. Die primär herausragende Eigenschaft von dd ist allerdings die blockweise Verarbeitung und die nächst wichtigere die Konvertierung, weshalb das da ja auch schon 2 Absätze vorher da steht: "dd copies input to output with a changeable I/O block size, while optionally performing conversions on the data."

Also was bringt diese Erklärung überhaupt, wenn sie für die Verwendung überflüssig ist, und noch nicht mal wirklich "erklärend" oder gar richtig?