Gehen Sie auf sehr große Dateien

465
Thibault

Ich habe 2 sehr große Dateien (27G und 40G), die ddauf einer fehlerhaften Festplatte den Befehl ausgeben . Ich wollte die ersten Bytes vergleichen, um zu sehen, ob die 27G-Bytes der Anfangs- / Teilstring der 40G sind.

Ich wollte den headBefehl verwenden. Da diese Dateien binär sind, habe ich -cArgument verwendet:

# ls -ahl *.dd -rw-r--r-- 1 root root 40G May 17 20:16 mac.dd -rw-r--r-- 1 root root 27G May 18 09:47 mac2.dd

Der Versuch, 1K Rohdaten zu erhalten:

# head -c1K mac.dd (returns nothing)

Versuch, 1K mit Hexdump zu erhalten:

# head -c1K mac.dd | hexdump 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 (end)

Versuch, 10K mit Hexdump zu erhalten:

# head -c10K mac.dd | hexdump 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0002800 (end)

Obwohl:

Versuch, 100 Byte Rohdaten unter / bin / ls abzurufen:

# head -c100 /bin/ls  ELF>�H@@p�@8 @@@@@@�

Versuch, 100 Byte Hex-Daten unter / bin / ls abzurufen:

# head -c100 /bin/ls | hexdump 0000000 457f 464c 0102 0001 0000 0000 0000 0000 0000010 0002 003e 0001 0000 4880 0040 0000 0000 0000020 0040 0000 0000 0000 b670 0001 0000 0000 0000030 0000 0000 0040 0038 0009 0040 001c 001b 0000040 0006 0000 0005 0000 0040 0000 0000 0000 0000050 0040 0040 0000 0000 0040 0040 0000 0000 0000060 01f8 0000  0000064

Die Ergebnisse auf der mac2.dd sind genau die gleichen, aber es scheint, dass die Ausgabe nicht wirklich das ist, was ich erwarte. Ich glaube nicht, dass die Dateien mit den gleichen Daten beginnen. Binär /bin/lsbin ich, was ich erwartet hatte.

Ich verstehe diese Ausgabe von ddDateien nicht. Kann mir das bitte jemand erklären?

Vielen Dank.

3
Zu Ihrer Information: `ddrescue` wird dringend für ausfallende Laufwerke empfohlen, da es intelligent nach fehlerhaften Lesevorgängen sucht, um so viel wie möglich wiederherzustellen. Sie hätten diesen manuellen Vergleich gänzlich vermieden. (Hinweis: `ddrescue` befindet sich im Paket 'gddrescue' auf Debian / Ubuntu-Systemen. Das ältere` dd_rescue`-Skript befindet sich im Paket `ddrescue`.) Bob vor 8 Jahren 1
Leider ist dies tatsächlich eine Datei von `ddrescue` ... Vielen Dank für Ihren Kommentar. Thibault vor 8 Jahren 0
Ah, das würde die leeren Dateien (oder Teile von Dateien) erklären - das muss das sein, was aufgrund von Lesefehlern übersprungen wurde ... Bob vor 8 Jahren 0
Sie haben Ihre Frage beantwortet, aber ich wollte nur erwähnen, dass "(gibt nichts zurück)" tatsächlich tatsächlich viele NULs zurückgegeben wurden, die nichts angezeigt haben. Mark Hurd vor 8 Jahren 1
@MarkHurd Total genau. Thibault vor 8 Jahren 0

1 Antwort auf die Frage

4
Thibault

Ich antworte mir.

Ich habe in diesem Beitrag herausgefunden, dass " *" in Hexdump "dasselbe wie die vorherige Zeile" bedeutet. Das bedeutet, dass meine gesamte ddDatei mit \0Zeichen gefüllt ist .

Ich kann es explizit machen mit:

head -c1000 mac.dd | hexdump -v 0000000 0000 0000 0000 0000 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 0000030 0000 0000 0000 0000 0000 0000 0000 0000 0000040 0000 0000 0000 0000 0000 0000 0000 0000 [...]

Oder kürzer:

# hexdump -v -n1000 mac.dd 0000000 0000 0000 0000 0000 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 0000030 0000 0000 0000 0000 0000 0000 0000 0000 0000040 0000 0000 0000 0000 0000 0000 0000 0000 [...]

Jetzt weiß ich, dass die ddMüllkippe mit nichts gefüllt ist.

Danke für jeden, der mein Problem hier unten gelesen hat.

Verwandte Probleme