Слетела файловая система на переносном жёстком диске
 

У меня проблема следующего характера: слетела файловая система на переносном жёстком диске. На нем слетела файловая система и теперь при открытии просит её форматнуть. Можно ли восстановить файловую систему, не форматируя HDD, или же всё-таки придётся форматировать? И если да, то какой лучше программой восстанавливать данные, а то на нем очень много нужной и дорогой информации, причем под завязку.

chkdsk /f ( диск: ) не восстанавливает?

poisonkit, Просто так разделы не слетают, --- поэтому:

1. Возьмите утилиту HDDScan, --- прочитайте ею SMART и покажите.

2. Выполните то, что я Паша-Север советовал
См. пост Tau_0 Отправлено: 16:28, 05-02-2012 в теме
HDD - не заходит на хард
http://forum.oszone.net/post-1852294.html#post1852294

ЗЫ Пока не используйте никаких авторекавери программ, --- на автомате можно испортить...

Есть хорошая прога - Active Partition Recovery . Может восстановить всю файл систему со всем барахлом без копирования на другой хард.
Но смарт не помешает показать..

Таки эффективнее инфу восстанавливать на исправный беспроблемный жёсткий диск, а не на повреждённом инвалиде перезаписывать инфу, которую так ещё и легче потерять окончательно.

Согласен, это надежнее всего. Но если нет под рукой лишнего накопителя то в принципе не вижу опасности от применения Active Partition Recovery. Она не трогает файлы, а только воссоздает заново таблицу MFT PT. Не получится.. тогда да, любым рековери на др.диск.

Из названия утилиты (я ею не пользовался...) следует, что она восстанавливает PT ( Partition Table/ Таблицу Разделов ). А вот создать новую MFT --- Главную Таблицу Файловую Таблицу, --- это тронуть файлы и наверняка положить файловую систему.

Что-то Вы здорово напутали...

ЗЫ Безопаснее всего вручную восстановить Таблицу Разделов, используя дисковый редактор DMDE.

прав.. нето вписал. Прога безусловно для PT. Но от этого суть всего не меняется. Принцип работы у нее тот-же что вы и предлагаете, только проще (особенно для обывателя). После сканирования выходит дерево разных ф-систем побывавших на диске и останется только выбрать нужную (она сразу будет видна по объему занятого и содержанию).

Жесткий диск Seagate 500Gb... только что прочитал сообщение... сейчас попробую прочитать смарт.

Добрый день всем. Внешний жесткий USB 3.0 на 2TB Toshiba - там вся жизнь. Долго просился на проверку, я несколько раз соглашался но по пол часа ждал - больше времени не было и перезагружал ресетом. В очередной раз после такого - он в системе как RAW - зайти не получается - пишет файл или папка повреждены - чтение невозможно. Chkdsk пишет исправление ошибки в индексе $0 файла 25 и на этом стоит часами (сегодня попробую на ночь оставить надеюсь не сожрет инфо). Acronis видит его как NTFS и при нажатии правой кнопкой, даже открывает список файлов. Пробовал Victoria проверить на Bad ы - не получилось - я так понимаю из за того, что там контроллер USB она не может его запустить. Помогите советом пожалуйста.

Нужно использовать специализированные программы по типу GetDataBack или HandyRecovery.
А вот хранить всю инфу в одном месте - не совсем правильно.

Спасибо - сейчас вроде так и делаю - вручную вытягиваю всё через R-Studio, она все видит и спокойно извлекает, странно что не получается просто восстановить загрузочную область т.к перетягивать 2TB восстановлением - это нужно искать еще 2TB )

Никто, кроме детишек, сейчас так не перегружается ---- обязательно рано или поздно потеряете информацию...

Согласно рапорта SMART физически хард исправен.
Следовательно нечно нехорошее случилось с информацией на самом харде. Поэтому до вытаскивания информации специализированными утилитами, как советует DVDshnik, имеет смысл посмотреть хард в дисковом редакторе. Возможно, что можно сделать некоторые корректуры и вылечить "малой кровью".

1. Возьмитете дисковый редактор DM Disk Editor and Data Recovery - DMDE 2.8.0
http://dmde.ru/download.html
И покажите в нём для начала скрин окна физический диск для Вашего харда.
См. на кортинке справа. http://dmde.ru/images.html

2. И из управления дисками картинку покажите свой RAW
Пуск ===> Выполнить ===> diskmgmt.msc

Согласен - но выбора не было. Был в гостях, а ноутбук начал делать эту проверку при запуске и через пол часа ничего не изменилось - ждал до последнего - потом пришлось выбирать либо ехать домой с ноутом от батарейки и висящим на шнуре работающим HDD либо вырубить. Когда выключал даже предчуствие было что хорошим это не кончится. Сейчас R-Studio тянет понемногу папки на другой внешний HDD 2 TB - но очень медленно т.к тот старый 3.5 с питанием еще и USB 2.0

alex2301ua, из скрина DMDE видно, что таблица раздела цела. Более того индикаторы DMDE EBCF показывают, что и с томом гуд… Но с Ваших слов это не так этот не так. Не думаю, что у Вас очень страшно...
Значит ВСЕ все неприятности связаны с файлом $MFT… Теперь надо на эти файловые записи хоть частично посмотреть, но для этого для них надо добраться...

Пришлите дамп десяти секторов, начиная с сектора LBA=2048
Вот так в DMDE в меню
Сервис ===> Копировать секторы…
См. для примера картинку.


На ней незамысловато 10 секторов копируются в файл…( Имя самого файла dev1_lba2028_10.bin меняить не надо ---- оно мнемонично…). Маршрут для файла выбираете свой… Я копирую по маршруту E:\Ответ\OSZone\alex2301ua\ в файл dev1_lba2028_10.bin

Дамп этих секторов (файл) присоединяетете к ответу.
И это ещё не ВСЁ, но пока не видно...

Сделал все как описано. Благодарю за подсказки. Да действительно и Acronis и R-Studio - пишут что с диском все нормально - R-studio еле еле вытягивает папки - нажатием восстановить, всю структуру папок видит отлично. А вот доступа к диску нет, пробовал на нескольких компьютерах XP Win 7 Win 8 - пишет файл или папка повреждены - чтение невозможно. Файл загрузил - только добавил txt - в конце чтоб его приняло тут.

alex2301ua, Теперь пришлите:
1. дамп 50 (пятидесяти) секторов, начиная с LBA = 2048 + 786432*8 = 6293504. Это для $MFT
2. дамп 8 (восьми) секторов, начиная с LBA = 2048 + 16*8 = 2176. Это для $MFTMirr. Там того зеркала всего на четыре записи, --- ещё не помню, чтобы хоть раз оно помогло…

Итого два файла надо…

Я дамп сделал с 2048 - 50 секторов и с 2048 - 8 секторов
Как пользоваться этими цифрами, сорри не понял :( LBA = 2048 + 786432*8 = 6293504 если что-то не так, переделаю.

Не то... --- надо 50 секторов, начиная с LBA = 6293504
и
8 секторов, начиная с LBA= 2176.
Переделайте...
Зря я слагаемые расписывал...:(

Аааа - теперь понятно. Переделал.

Теперь правильно.
Бегло просмотрел первые 25 файловых записей (это как раз 50 секторов --- по два сектора на файл). Число внешне вроде как записи вполне приличные и явных косяков в них я не увидел...
Но поскольку
То возможно имеет смысл побаловаться и затереть Hex нулями эту 25 ую записиь (можно предварительно сохратить её) --- Бох с ним с этим файлом, а вдруг чекдиск колдобину проедет и дальне оно нормально поедет...???...
Кто, что по этому поводу думает...???...
А то лихой кавалерийской атакой не получается...:(

Сейчас довытягиваю важные файлы из диска т.к очень долго это всё происходит. Затем попробую затереть нулями запись. По поводу hex и где она там вообще, появились вопросы :)

Подскажите - как эту запись затереть? Я с диска уже все необходимое вытянул. 2 дня понадобилось, чтоб 1.5 TB с помощью R-Studio восстановить. Пытаюсь в DMDE найти её, но не получается.

Там достаточно просто, хотя…
В первом загрузочном секторе тома в Вашем случае по адресу LBA=2048 хранится вот такая таблица.
Если глянуть в форматном просмотре, то увидим картинку.


Нас интересуют файловые записи или записи $MFT
Их начало показано как 786432 кластер (LCN) относительно начала тома. Тогда в секторах это будет 786432*8 = 6291456 сектор (учитываем, что в кластере восемь секторов).

А относительно начала харда файловые записи начнутся в секторе 2048 + 6291456 = 6293504

Вот с сектора 6293504 и начинаются записи MFT. Эти записи в Вашем случае по 1024 байтов каждая и описывают все файлы и каталоги на томе. Записи можно просто посмотреть, но я не увидел чего-то нехорошего, что-бы оно бросилось в глаза…

Выходим на файловые записи и их читаем/смотрим….
На мой взгляд удобнее всего просматривать записи MFT в дисковом редакторе WinHex.

А вот теперь пока ВСЁ. Чтобы баловаться с этим делом дальше Вам придётся кое-что почитать… Если у Вас есть на это время, то я готов буду продолжить дальше. А просто читать мои писули, как лёгкое чтиво и разбирать это дело не получится… --- Тут разобраться малость надо, --- вопрос не простой…

Поэтому решайте… Но можете на досуге необходимо посмотреть
Книга: Криминалистический анализ файловых систем
Автор: Брайан Кэрриэ
Год издания: 2007 г.
Страниц: 480 стр.
Формат: DjVu
Размер: 7.28 MB
http://www.kodges.ru/komp/8313-krimi...kh-sistem.html

Спасибо, книжку скачал, почитаю на досуге. Благодарю за помощь в этом вопросе. Сам такой же, кадетов отправляю читать матчасть, когда устаю отвечать на глупые вопросы, поэтому прекрасно вас понимаю)

Поехали дальше....
Для того, чтобы подступиться к NTFS мы начачали с метафайла $Boot. Это единственный файл с жёстко заданный местоположением, --- остальные файлы могут быть где угодно…

На записи MFT мы тоже вышли ---- они начинаются с LBA = 6293504. И первые 25 записей (50 секторов) Вы мне прислали.

Я просматриваю эти записи в дисковом редакторе WiinHeх. И вижу примерно такое
http://rghost.ru/54407062/image.png

В шестнадцатеричном виде смотреть не всегда удовно, поэтому применяем шаблон
VIEW ===> Template menager ===> NTFS File Record
http://rghost.ru/54407129/image.png

Порой такой просмотр в определённом смысле более информативен

Навскидку я ничего плохого в записях не усмотрел, это совсем не означает, что ничего плохого нет.

У Вас хард под рукой и смотреть Вам записи не пересмотреть, а записей в MFT немеряно…:gigi::gigi::gigi:

Открыл $Boot, как вы описали

Я так понял можно по номеру кластера понять, что это за файл (WinHex показывает это в правом нижнем углу) - если найти где этот "индекс $0 файла 25"
хотя я уже всё нужное с диска вытянул и это не имеет значения. Может просто заменить нулями весь этот файл 25 - только как его найти я так и не разобрался, зато нашел как забивать нулями )

alex2301ua, я Вам советовал поковыряться/посмотреть подозрительные записи MFT… При этом я написал, что в первых 25 записях я визуально ничего плохого не обнаружил…

Но тут есть одна незадача ---- если Вы внимательно прочитали что пишет Брайан Кэрриэ про файловые записи, то должны были заметить, что нумерация записей идёт с нуля, поэтому последняя запись в дампе была с номером 24. Маловато будет, однако даже до 25 я не дотянулся...

Из той картинки, что Вы прислали Выглядит тоже ВСЁ красиво, но только том не монтируется и чекдиск заклинивает…

Поэтому пришлите ещё 50 секторов (надеемся, что разрыва в записях MFT не будет…) начиная с LBA = 6293504 + 50 = 6293554

Начиная с 6293554 сектора пришлите ещё 50 секторовов (это 25 записей будет), учитываем, что первые 25 записей у меня уже есть. На харде этих файловых записей может быть миллионы, но обычно неприятности начинаются, когда, плохо с системными метафайлами (это где-то первые 16 записей), а тут и пользовательские файлы заклинило…???...

Вот 50 с 6293554

И 50 с 6293504

Если забить нулями с 6293504 - 6293554 - мы попадем по этому файлу из за которого Chkdsk буксует?

Посмотрел…
И эти записи вроде как тоже нормальны….
Не знаю я в чём там дело... :dont-know

Мой Вам совет ---- сходите на хобот в тему
Помощь в восстановлении информации с HDD (часть 5) (Страница 32) и озадачте тамошний народ. Они ближе по духу к в вашей проблеме будут и разработчик DMDE там постоянно обретает, жаль, что Antec пропал, но другие остались....

Так мол и так, --- утилитами типа R-Studio файлы выбираются, но том не монтируется и чекдиск зависает.... И редактор DMDE показывает по индикаторам исправный том, --- как поймать козу и отремонтировать том in-place. ..???... Должен он ремонтироваться и ВСЁ тут.

Добавлено
=======
Ни в коем случае...!!!...
С сектора 6293504 начинается таблица MFT. это первые её записи См.
NTFS System Files этим вы атрёте метафайлы и ничто не смонтируется. На запись по два сектора идёт...

Tau_0, я на хоботе написал.
А какой может быть способ найти где находится индекс $0 файла 25 - чтоб его затереть Hex нулями?

Сделал все как посоветовали на хоботе. В DMDE открыл диск, затем в меню Редактор - Файл MFT (Alt+F) - ввел 25
нашел файл $ObjID - про него http://hex.pp.ua/object-id.php.
Занулил этот сектор (создав dump) на всякий случай
попробовал Chkdsk - он завис уже на другом этапе

затем восстановил dump - chkdsk все равно зависает на этапе

Остаётся констатировать, что утилита чекдиск не всемогуща….
Вот нагуглил похожее ---- C:\$Extend\$Objid поврежден и не может быть прочитан. Запустите служебную программу CHKDSK.. Здесь ТС проблему не решил и к разгадке не приблизился. И тем похожих очень много…

Везде советуют чекдиском беду лечить, но не многим она помогает. Вся беда в огромном количестве файлов и индексов. Эти самые атрибуты $INDEX_ROOT, INDEX_ALLOCATION для вытаскивания файлов и не очень то нужны (в том смысле, что R-Studio и другие утилиты восстановления обходятся без них). Но для высокой скорости работы NTFS использует эти B+ деревья. Но если индексы становятся неверными/противоверичыми не совсем понятно как их вылечить…

ЗЫ Видел Ваши посты на хоботе и мудрствования 9285, которые можно свести к тому, что FS NTFS испортилась и простого метода её лечения он тоже не знает. Я могу посоветовать только разные версии чекдиска попробовать --- авось в Microsoft научились собственнуб ФС ремонтировать…???...

Tau_0, я пробовал разные Chkdsk Win 7 Win 8 Acronis - результат тот-же. Форматнул диск. Ошибок не было. При копировании обратно файлов было в две ошибки CRC - одна в музыкальном файле, одна еще в каком-то не важном. Остальное все вернулось на место. Я понял что тут долго можно искать варианты, и решения этой проблемы там не знают, поэтому не стал тянуть время дальше, а то вся инфа лежит на страреньком backup 2TB 3.5 HDD а новый 2.5 2TB - лежит все как полутруп)
Да, он так расписал как для совсем уже отсталых. Сказал бы просто - незнаю решения этой проблемы )

Не совсем понятно, --- ваш внешний Toshiba размером 2 TB, а не 2.5 TB. И если Вы его отформатировали по новой, то почему он полутруп...???... На нём должна быть новенькая, как пишут буржуины некоррумпированная файловая система, у которой ВСЁ ещё впереди...:gigi::gigi::gigi:

Опять же по поводу контролля по CRC неясно как вы его реализовали...???... Это ведь предварительно надо было контрольные суммы считать... А если суммы в файлах изменились, то вроде к файловой системе (сбоям в ней) это прямого отношения не имеет.

Просто не идеальна сама FS NTFS, ---- несмотря на все хвалёные механизмы восстановления ФС далеко ей до совершенствтва. В сети полно тому примеров помимо Вашего. Вот и здесь был вчера пост 9285 (потёрли его за старые заслуги...:( ), где он писал, что ФС обслуживать правильно надо. Конечно надо, но не всегда получается, и случается... Поэтому, как и сто лет назад, надо делать BACKUP --- другого не дано...

Согласен. Backup делал, просто давно не обновлял. Вот теперь обновил. Жесткий как я и писал 2TB (2.5 дюйма - это формфактор) а другой 2TB, который Backup 3.5 дюйма с питанием. После того как восстановил с него все на Backup диск - он лежал несколько дней, как труп) пока я тут пытался найти способ "оживить" файловую систему. После того как отформатировал - скопировал на него все назад (что вытянул с помощью R-Studio) - вот когда копировал - было пару файлов которые не скопировались - при перетаскивании папки с этим файлом - копирование пролетало моментально (хотя папка не маленькая) - но в новом месте ничего не появлялось, пришлось по кусочкам перетаскивать и в итоге были найдены пара файлов из за которых вся папка так себя вела, при попытке их удалить - вышло сообщение Ошибка CRC и они не удалились. Слава богу они не важные, а всё необходимое скопировалось.

Прошу помочь. Случайно эксперементируя с Андроидом 7, запустив его на флешке, отформатировал USB HDD в Fat32. Как вернуть все обратно? На терабайтнике стояла NTFS и диск был забит под завязку. Как я понимаю, надо восстановить PT? Справится ли с этим Active Partition Recovery? Было бы идеально просто вернуть старую PT на место. Или моя проблема сложнее?
HDDScan ошибок не находит.

Совсем недавно нечто похожее уже было...
Посмотрите тему HDD - Возможно ли и как восстановить данные с внешнего жесткого диска в этой ситуации?

А сейчас покажите скрин окна Разделы диска... из дискового редактора DMDE

После просмотра этого окна дальше думать будем...

pokrov, Желательно под Администратором.
Где Х буква вашего диска.
Без потери данных.

Ни в коем случае --- нельзя НИЧЕГО писать на проблемный внешний дик...!!!...

Если диск есть под заплады, ради бога.
А я разве сказал что можно. Хватит орать.

О...!!!..:o Мсье знает толк в извращениях...!!!...
Начинайте с любого...
А где информация...???... :cool:

Добавлено
=======
При потытке открють любой из трёх фалов пишет ===>
Добавлено
=======
А я по прежнему не могу открыть Файл 145506, Файл 145507, Файл 145508

Снова Добавлено
============
Как-то не так Вы ссылки создаёте. У себя Вы их видите потому, что видимо ссылка идёт на то, что есть только на Вашей машине...
Если не получается выложить на форум (бывает, что и неудобно, потому, что чило/ёмкость вложений ограничена...) --- выложите на внешний обменник, например на rghost.ru

ЗЫ Смех и грех..., но я впервые здесь на зоне такое встречаю, когда не никак могу посмотреть :(

Благодарю за благосклонность.
Я вообще-то сразу три диска испортил. Пошлю информацию о каждом. Может быть с каким-то из них более предпочтительно будет начать разбираться.

1) Transcend 1 Tb
http://rgho.st/79vq8Q8nb
2) WD 500 Gb
http://rgho.st/8YBBjv7V9
3) Seagate 500 Gb
http://rgho.st/89VZysx2W


Тоже самое через "скрепку":
Файл 145514
Файл 145515
Файл 145516

У меня все открывается.
Они лежат не на мой машине, а на ОСЗОНЕ.

Теперь у меня тоже...
Запускайте на любом из них (хардов) Полное сканирование.
По окончании показываете лог сканирования...

ЗЫ Короче, действуйте согласно указаниям в теме HDD - Возможно ли и как восстановить данные с внешнего жесткого диска в этой ситуации?

Вот, посмотрите пожалуйста, результат полного DMDE сканирования диска Seagate:
http://rgho.st/6L42ggGz9
http://rgho.st/6qqd42mps

Подскажите, что делать дальше правильным образом.

В DMDE загрузил log-файл DMDE (Seagate).log и вижу, что найден том NTFS0 c началом в LBA = 48 258, а конец тома неведом…
Ещё видно что на томе найдено 1 484 284 файла. Насколько они все живые неизвестно...
См. картинку во вложении.
Других (кроме NTFS0) предполагаемых NTFS томов не найдено. В более сложных и запутанных случаях, порою много томов находится...
Но здесь этого нет.

Не совсем понятно, почему том так далеко начинается...???... FirstLBA = 48 258
Переведём это начало из секторов в байты, считая, что в секторе 512 B..
48 258 * 512 B = 24 708 096 B = 24 708 096 /1024/1024 MiB = 23.5634765625 MiB ~= 24 MiB
Отступ тома от начала харда ~= 24 MiB

Если и был перед этим разделом/томом другой том, то форматом он безнадёжно затёрт.

А дальше просто…, --- в DMDE запускаете полное сканирование и загружаете сохранённый лог. При этом сканировать по новой не будет. Открываете картинку и шарите в паке $Root на предмет наличия нужных файлов. Если таковые есть, то вытаскиваете их на сторонний носитель…

Потом файлы надо будет проверить на целостность --- открыть их с носителя, на который сделали восстановление. Открывать их надо как обычно с помощью соответствующих Windows приложений.

Рефлексии по ходу Вашего сообщения.

Да, не так давно этот Seagate был разбит на два раздела. Позднее я Акронисом первый его подшил ко второму. Возможно этим объясняется факт, что NTFS0 записан не в начале диска. Так что старый первый раздел мне не нужен.
------------------------

Так видимо у меня на Transcend (1 Tb)
r.saver находит на нем несколько десятков NTFS, FAT и FAT32.
Файл 145556
Если восстанавливать через r.saver, то видимо следует выбрать один соответствующей NTFS? (В моем случае был один раздел).
Я обращаю внимание на первую, в отличии от остальных имеющую метку "Transcend".

Наличие такого множества данных записей меня удивило. Чем их наличие вызвано не понятно.

-------------------------------

Я выбрал реконструкцию по умолчанию и получил весьма утешительный результат.
Файл 145558

Теперь, если я благоразумно сохраню на другой диск все что ценно и необходимо, могу ли я попытаться одним махом попробовать восстановить прежний формат диска? Напр. командой convert X: /fs:ntfs, которую Вы прежде строго раскритиковали? Или каким-то другим способом?

pokrov, посмотрел ещё раз на скрин окна Разделы диска… для харда 1 TB Seagate
и обнаружил, что просмотрел реликт NTFS тома :(
FirstLBA = 48 264
LastLBA = 976 768 064

Вот этот реликт поставил меня тупик. Мне непонятно, --- почему FirstLBA = 48 264, а не 48 258…???...
Поэтому пришлите мне дамп 20 секторов, начиная с LBA = 48 250
Дамп делается так ---
в меню Сервис ===> Копировать секторы
Заполняете шаблон
Источник
===============
Хард Seagate
Начальный сектор ---- 48 250
Конечный сектор --- заполнится само…
Число секторов --- 20

Приёмник
================
Файл --- У меня это F:\Ответ\OSZone\pokrov\dev0_lba48250_20.bin
Имя файла (dev0_lba48250_20.bin) переименовывать не надо --- оно мнемонично
Этот файл выложите на обменник.

См. картинку

ЗЫ Последний Ваш пост пока не обдумал, --- этот ответ не на него...
Замечу только, что не могу открыть Файл 145558 ...

Добавлено
=======
Эта команда конвертирует FAT в NTFS, т.е. своим нечистым рылом вконец замутит с г-ом и илом то, что оставалось от файлов NTFS на месте, занимаемом теперь томом FAT32. --- Получите на выходе том NTFS c ненужной мутью…

А нужного на томе FAT32 нет. Более того, этот раздел/том в DMDE надо вообще удалить, во избежание…

Видимо вы слишком старый билд акрониса пользовали… ---- Старые билды акрониса не создавали копию бут сектора тома NTFS в конце раздела, поэтому от найденного реликта копии бута радости мало… Он к слишком ранней истории относится…
Какую версию акрониса использовали…???...
Но Вы всё-таки дамп пришлите, --- я покопаюсь в нём на всякий случай….

Если сомневаетесь насчет Акрониса, то я тоже не очень-то уверен, что именно им объединял партиции. Это могла быть и др. программа, напр. MiniTool Partition Wizard Или Paragon. Что касается версий, то я имею привычку все адаптировать.
-------------------------------
Дамп от Seagate. (Только он не 1Tb, а 500 Gb)
http://rgho.st/7vX2bGpLT

Это хорошо, что Вы потренировались...:), но плохо, что у меня в голове замкнуло :( --- Виноват...:blush2:
Для просмотра копии бут-сектора, нужен дамп 20 секторов, начиная с LBA = 976 768 050
А в секторах [48 250..48 269] теперь одни нули --- это формат бут сектор NTFS-тома нулями перекрыл...

Короче, ещё раз пришлите 20 других секторов, плз ===>
Хотя, как я уже замечал, радости от них особой не будет, но...

указываем без пробелов, вот так: 976768050

Дамп Seagate:
http://rgho.st/6nmsMMJqF
Здесь тоже "нули".
----------------------------

Удалось взломать. Можно и передохнуть.
Исходный код

А я с незначащими (но удобными как разделители) пробелами указал и нормально прошло
См. Картинку 1

Нет не нули...
По OffSet = 8 (относительно начала дампа), а фактически в секторе LBA = 976 768 050 + 8 = 976 768 058 харда расположена копия бут сектора тома NTFS.
См. Картинку 2

Эту копию бута DMDE при экспресс поиске не указал... Но мы её нашли...!!!...

И по OffSet = 14, а фактически в секторе LBA = 976 768 050 + 14 = 976 768 064 харда расположена другая копия бут сектора тома NTFS.
См. Картинку 3

Эту копию бута DMDE при экспресс поиске указал... Но она нам не нужна. Её расположение мне не понравилось... Я ранее указывал на это.

Загружаем эту копию в WinHex и смотрим в форматном просмотре...
См. картинку 4
К сожалению эта копия нам не подходит. Этот реликт от того раздела/тома, что когда-то был в секторе 63… Это слишком не то…

Можно было-бы побаловаться и изобрести boot-sector для тома с началом в LBA = 48 258, но не хочется с этим возиться… --- Пока попробуйте без этого нужное восстановить.

Могу я заняться. Это очень просто для меня.

Мало одного клоуна-калекаря - ещё один подтянулся с хобота (там тоже цирк не хуже). :laugh:

PS. Он и так есть, достаточно только записать в нужное место.
Да только толку от него как от всего написанного ранее Tau_0, который даже не понимает почему не найдено и ещё разные простые вещи.
Или какой толк видится в бутсекторе раздела у которого отсутствует более 80 тысяч записей - причём с самого начала? Можно не отвечать, так как уровень бескомпетентности мне и так известен.

До Вашего сведения:
У меня DMDE 3.0.6 не копирует Ваше число.

Уважаемый С Ваших слов я заключаю, что Вам моя ситуация более прозрачно ясна.
Какой бы Вы способ могли предложить? Как Вы уже прочитали, я отформатировал несколько USB HDD (по одному разделу на каждом) переделав NTFS на FAT32. Этот случай на мой взгляд из ряда стандартных, распространенных и должен иметь стандартное исправление. Но пока в инете я его не нашел его описания и инструкции исправления.

pokrov
Вообще то случай не стандартный, особенно в части трёхкратного повторения. ;)
В определённых ситуациях он бы и мог иметь стандартное решение, но это если бы ты пользовался стандартными средствами форматирования (при формировании разделов NTFS). Это относительно сигейта, потому как про другие пока инфа поверхностная.

В любом случае, здесь мне не дадут тебе помочь, так как то, что я пишу вызывает неконтролируемое мочеиспускание у здешнего вертухая, в результате чего он банит ник - причём даже только зарегенный. ;)

Приходи в http://forum.ru-board.com/topic.cgi?...4&topic=5216#1 - там можем продолжить.

Спасибо за приглашение. Пока практических сложностей с DMDE у меня не возникает. DMDE, благодаря советам Tau_0 рулит. Уже перелопатил WD и перезалил все, что на нем было почти без ошибок. Думаю так будет с двумя другими, - ситуация аналогичная. Но так и не понимаю до сих пор, как восстановить диски в первоначальном виде т.с. одним махом, восстановив прежний формат. Везде пишут, что это опасно. Но если я все с них бекапировал, можно теперь, благородное дело, и рискнуть.
Только я не знаю как это лучше сделать. В общем, остался теоретический интерес.

Как минимум с сигейтом восстановление на другой носитель по файловой системе не получится.
И восстановление по месту тоже - если подразумевать более менее полное.

Тут я малость виноват :blush2: --- пост набирал через буфер в Ворде, не в блокноте...

И получилось так, что вместо пробела попал неразрывный пробел Ворда. Хоть внешне оно выглядит как пробел, но на самом деле там не простой ASCI пробел... Я его без задней мысли в HTML ффф-торкнул... :(

И Вы по copy/past этот неразрывный пробел при вставке использовали.... Вот DMDE и воспротивился...