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

[Tau_0]

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

[alex2301ua]

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

[alex2301ua]

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

[Tau_0]

Пытаюсь в DMDE найти её, но не получается. »
Там достаточно просто, хотя…
В первом загрузочном секторе тома в Вашем случае по адресу LBA=2048 хранится вот такая таблица.
Если глянуть в форматном просмотре, то увидим картинку.
http://rghost.ru/54317560/image.png

Нас интересуют файловые записи или записи $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-kriminalisticheskijj-analiz-fajjlovykh-sistem.html

[alex2301ua]

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

[Tau_0]

книжку скачал, почитаю на досуге. »
Поехали дальше....
Для того, чтобы подступиться к 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:

[alex2301ua]

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

Я так понял можно по номеру кластера понять, что это за файл (WinHex показывает это в правом нижнем углу) - если найти где этот "индекс $0 файла 25"
хотя я уже всё нужное с диска вытянул и это не имеет значения. Может просто заменить нулями весь этот файл 25 - только как его найти я так и не разобрался, зато нашел как забивать нулями )
http://s020.radikal.ru/i722/1404/d9/5253f81b2ae2.jpg

[Tau_0]

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

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

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

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

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

[alex2301ua]

Вот 50 с 6293554

[alex2301ua]

И 50 с 6293504

[alex2301ua]

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

[Tau_0]

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

Мой Вам совет ---- сходите на хобот в тему
Помощь в восстановлении информации с HDD (часть 5) (Страница 32) (http://forum.ixbt.com/topic.cgi?id=11:45814-32) и озадачте тамошний народ. Они ближе по духу к в вашей проблеме будут и разработчик DMDE там постоянно обретает, жаль, что Antec пропал, но другие остались....

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

Добавлено
=======
Если забить нулями с 6293504 - 6293554 - мы попадем по этому файлу из за которого Chkdsk буксует? »
Ни в коем случае...!!!...
С сектора 6293504 начинается таблица MFT. это первые её записи См.
NTFS System Files (http://ntfs.com/ntfs-system-files.htm) этим вы атрёте метафайлы и ничто не смонтируется. На запись по два сектора идёт...

[alex2301ua]

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

[alex2301ua]

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

[Tau_0]

попробовал Chkdsk - он завис уже на другом этапе »
Остаётся констатировать, что утилита чекдиск не всемогуща….
Вот нагуглил похожее ---- C:\$Extend\$Objid поврежден и не может быть прочитан. Запустите служебную программу CHKDSK. (http://virusinfo.info/showthread.php?t=18965). Здесь ТС проблему не решил и к разгадке не приблизился. И тем похожих очень много…

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

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

[alex2301ua]

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

[Tau_0]

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

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

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

[alex2301ua]

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

[pokrov]

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

[Tau_0]

отформатировал USB HDD в Fat32. Как вернуть все обратно? На терабайтнике стояла NTFS и диск был забит под завязку. »
Совсем недавно нечто похожее уже было...
Посмотрите тему HDD - Возможно ли и как восстановить данные с внешнего жесткого диска в этой ситуации? (http://forum.oszone.net/thread-326446.html)

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

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