Голова на очень большие файлы

375
Thibault

У меня есть 2 очень больших файла (27G и 40G), которые выводятся ddкомандой на неисправный жесткий диск. Я хотел сравнить первые байты, чтобы увидеть, являются ли байты 27G началом / подстрокой 40G.

Я хотел использовать headкоманду. Поскольку эти файлы являются двоичными, я использовал -cаргумент:

# 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

Попытка получить 1K необработанных данных:

# head -c1K mac.dd (returns nothing)

Попытка получить 1K с помощью hexdump:

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

Попытка получить 10K с помощью hexdump:

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

Хотя:

Попытка получить 100 байт необработанных данных в / bin / ls:

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

Попытка получить 100 байтов шестнадцатеричных данных в / bin / ls:

# 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

Результаты на mac2.dd точно такие же, но, похоже, результат не совсем тот, который я ожидаю, поэтому я не думаю, что это означает, что файлы начинаются с одинаковых данных. Голова на двоичном /bin/lsэто то, что я ожидал.

Я не понимаю этот вывод ddфайлов. Может кто-нибудь объяснить это мне, пожалуйста?

Спасибо.

3
К вашему сведению: `ddrescue` настоятельно рекомендуется для сбойных дисков, так как он разумно ищет сбойные чтения, чтобы восстановить как можно больше. Вы бы полностью избежали этого ручного сравнения. (Примечание: `ddrescue` находится в пакете` gddrescue` в системах Debian / Ubuntu. Более старый скрипт `dd_rescue` находится в пакете` ddrescue`.) Bob 8 лет назад 1
К сожалению, на самом деле это файл из `ddrescue` ... Спасибо за ваш комментарий. Thibault 8 лет назад 0
Ах, это объясняет пустые файлы (или части файлов) - это должно быть то, что было пропущено из-за ошибок чтения ... Bob 8 лет назад 0
Вы ответили на ваш вопрос, но я просто хотел упомянуть, что ваши «(ничего не возвращает)» действительно вернули много NUL, которые ничего не отображали. Mark Hurd 8 лет назад 1
@MarkHurd Совершенно точно. Thibault 8 лет назад 0

1 ответ на вопрос

4
Thibault

I'm answering myself.

I found out from this post, that the "*" in hexdump means "same as previous line". Meaning that my whole dd file is filled with \0 chars.

I can make it explicit with :

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 [...]

Or in a shorter way :

# 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 [...]

So now, I know that the dd dump is filled of nothing.

Thanks for anyone who read my problem down to here.

Похожие вопросы