Форум iHDD.RU

[Stamm]

Здравствуйте гуру!

Несколько дней назад освоил MHDD v4.5 по случаю знакомства с винтом Maxtor с убитыми секторами, и один из них - нулевой.

Некоторые параметры таковы (сообщает MHDD):
Maxtor 6E030L0 LBA: 60,058,656 SN: E10KXRGE FW: NAR61590

Прочитав документацию и FAQ, приступил к лечению. Правда, допустил роковую ошибку. ERASE можно было применять точечно для сбойных секторов, а я решил стереть весь хард, предварительно слив образ.

Я заюзал команду ATOF, и прога слила 29 файликов по ~1 Гб на запасной хард. После этого натравил тотальный ERASE и о, чудо, все бэд блоки (UNC, AMNF) исчезли, кроме одного сектора с доступом <150 ms, что не очень пугало, т.к. это износ поверхности.

Но основная проблема меня ещё только поджидала - при заливке образа назад MHDD не понимает созданные ей же цепочки файлов-образов, а только принимает их поштучно с указанием номеров секторов. Ну ладно, 6-7 часов я записывал последовательно образ назад на диск. А когда записал последний, обнаружил, что до конца диска не хватает около 3 млн. секторов. Перепроверил запись. В одном месте нашел сдвиг по моей вине на 20 секторов. Но кроме того, я обнаружил, что MHDD записывала файлы _разного_ размера. Если в куске обнаруживался сбойный сектор - она выкидывала его совсем из образа. Если сбоев не было - все честные 1,073,856,000 байт ложились в образ.

У меня два вопроса:
1) Можно ли заставить MHDD при сливе забивать нулями места сбойных секторов в образе?
2) Каким вы видите способ корректной заливки обратно на хард имеющегося образа?

[maysoft]

1) MHDD таки забивает нулями места сбойных секторов в образах. По крайней мере так делает последняя версия — 4.6
2) как вариант — собрать все образы в один в windows и затем натравить, например, R-Studio на получившийся образ.

[Stamm]

Спасибо за советы. 4.6 уже скачал, но не опробовал пока. Поискал R-Studio. Попробую конкатенировать файлики. О результатах отпишусь.

[Stamm]

Отчет'c.

Успешно слил образ с помощью WinHex 12.9 SR-14. Вышло, конечно, поменьше 30 Гб.

Натравил R-Studio network edition v3.5 (build 123505). Задал распознавать типы файлов. Оставил на ночь. Программа зависла где-то на 70% сканирования.
Утром пересканировал без распознавания и убрал поиск NTFS-кусков (их там по определению не было). Программа выдала невразумительный список "обнаруженных разделов" различной размерности (точек входа в директории).
Пересканировал под своим чутким надзором с распознаванием файлов - выдала ту же структуру, но более раскрашенную. Среди партиций нашел наиболее близкие - 5.9 и 16.3 Гб. Часть файлов перечеркнута (как бы удалённые файлы). Часть файлов вполне живая. Только это часть не большая. И директории находятся в хаосе относительно друг друга (просто свалены в кучу по номеркам).

Мне всё это не нравится. А в голове пытаюсь построить модель "вырезания" секторов из общего потока. Хочу нарисовать карту и распихать так как всё было.

Почему именно 255 секторов?
Вот пример лога:

[BadMaker]

Ситуация конечно интересная :)
Поскольку у нас ФАТ, то это несколько упрощает дело.
(Не знаю, может и в НТФС такой фокус возможен)
А вот то, что было несколько разделов - усложняет.

Первым делом надо разделить образ на разделы, отделить "мухов от котлетов". Сделать это можно по сигнатурам начала раздела, по ФАТу (его легко найти) и т.д. Получив 1 файл = 1 нерабочий раздел можно идти дальше.

Отрезаем от начала раздела ненужности, типа MBR, до самого начала раздела. Смотрим на заголовок. Нам нужно знать точный размер бпб, фата и размер кластера. Все. Даже если заголовок убит, все можно найти. Берем количество фат (обычно 2), умножаем на размер, прибавляем размер бпб = начало данных (или руками ищем). Если нету размера кластера, то ищем несколько каталогов ".[10 пробелов]", смотрим его кластер (он ссылается сам на себя, это главная фишка), высчтавыем расстояние, и делим на разность адресов кластеров - будет размер.

Итак, есть начало данных, есть размер кластера. Скорее всего проще написать прогу: бежим по всему образу, читая каждый сектор, как только найдем ". " в начале сектора (новый каталог), то проверяем его номер кластера, если он неравен расчетному ((текущий номер LBA-начало данных)/размер кластера+2), то "отодвигаем" его на нужное расстояние и бежим дальше. И пока не закончим. Часть файлов будет коцаная, но ничего не вернешь. Потом открываем раздел (под линухом желательно) и сливаем инфу.

Интересно, как поступил автор? :)