» Восстановление разделов и информации на HDD (часть 8)

[more] [more]
Цитата:

acrid2
Размер MFT 256 записей, что характерно для вновь отформатированного раздела.
Смущает только что есть папка Sony и некоторые файлы. Хотя это можно списать на то, что они прописались после формата (бывшим владельцем)?.
Впрочем, бывают разделы восстановления и с малым числом файлов (папок).

Добавлено:
Зачем мне содержимое метафайлов, если вопрос был про root?

Ну я не знаю, я же написал выше, что root пустой.

По поводу папки sony вот скрин части ее содержимого, которое я сохранил прогой hetman:
http://s019.radikal.ru/i636/1602/e2/34549ff58bf7.jpg
так вот что странно, у всех папок в ней( и не только в ней, а вообще все восстановленные папки) дата создания стоит 07.02.2016 т.е. когда я их восстанавливал и сохранил на диск.
А все файлы, во всех папках - дата создания 2010 год, то есть когда и записывался рекавери на заводе...

upd

хотя нет, рут не пустой...просто я заходил не в тот рут. погодите, делаю скрин

upd2

http://s017.radikal.ru/i403/1602/49/84438133ffe8.jpg [/more]

в общем, как я понял, там все настолько перемешалось, что восстановить если и возможно, то явно не самому, а везти куда-то этот диск смысла нет... Спасибо за попытку помочь! [/more]

acrid2
Если папки, файлы находятся хитманом, то они должны быть и в DMDE - удалённые или найденные, в руте или в папке Все найденные + реконструкция.

Цитата:

Если папки, файлы находятся хитманом, то они должны быть и в DMDE - удалённые или найденные, в руте или в папке Все найденные + реконструкция.

да, есть там эти папки. Вот они:
http://s017.radikal.ru/i435/1602/ef/6de181112a6c.jpg

acrid2
Насколько понял - папки пустые или в них мало (мелких?) файлов?
Если учесть что дата MFT - октябрь 2014 года, не удивлюсь ели подтвердится что бывший хозяин форматнул раздел.

temp9285

Цитата:
вот у меня в папке 0Huis еще была подпапка Gruz2016, а в ней еще несколько подпапок с данными.


Цитата:

Можно увидеть что в логе по поводу этих папок?

Checkdisk log. В файле 7.txt - отфильтрованные по именам файлов записи из этого лога. Но опять-таки повторюсь, что они тут не все, так нет ни одной из подпапок 0Huis\Gruz2016. Суды по всему и остальные подпапки из 0Huis, такие как ac , Bounces, Metelkin,Mix ,Pics безвестно канули. Что интересно у них у всех стоит чекдисковская метка - файл 113424. Я так понял, что в данном случае это признак одной и той же поддиректории, в данном случае 0Huis

Цитата:
судя по всему чекдиск снес подпапку Gruz2016, и соответственно о том, что было там внутри вообще никаких упоминаний нет.


Цитата:

Если даже снесена запись об этой папке, в записях MFT подпапок и файлов внутри неё, остался номер родительской папки. И, в отсуствии родительской, они как раз собираются в DMDE в папки типа $Fxxxx
Потому и писал о таких папках и о поиске по известным именам. Технически, можно поискать где фигурируют названия в хексредакторе и возможно что ситуация прояснится, но это очень муторно.
Дамп подтвердил подозрение в наличии расширенного атрибута в 0-вой записи, причём его "конструкция" для меня нова. Здесь уже было как то пара-тройка случаев с таким атрибутом, огромным числом записей (у тебя около 460 тысяч, но было и больше) и невиндовыми системами. Могу предположить что это как то взаимосвязано - ведь NTFS не документирована в полном обьёме, и всевоможные приблуды для работы с инородной ФС не гарантируют свою безошибочность.
Как то так.

Попробовал несколько поисков по именам, которые помню - ничего не нашлось. В папках $Fxxxx в основном файлы, которые были сознательно удалены и они как раз неинтересны.

Я не думаю, что тут вмешались сторонние системы - я записывал данные под семеркой, потом просто несколько раз втыкал этот диск в виртуальную винду на маке, но это не портило файлы. А испортил как раз чекдиск, который я опять-таки запускал на семерке.

avtandil33
Мне не очень понятны некоторые записи (терминологии) чекдиска, но попробую пояснить что мне видется.

Неверный нерезидентный атрибут типа 0x80. Правильная длина данных 0x28b00000,
размер файла 0x28b00000, выделенная длина 0x222bf000.
Судя по всему, речь идёт о упоминаемом расширенном атрибуте в 0-вой записи.
Правильная длина и размер файла (в десятичных) - 682622976, а выделенная длина 573304832.
Последнее значение как раз фигурирует в 80-м атрибуте. Если учитывать что размер стандартной записи 1024 байта, то в файле такого размера может быть информация о 559868 записях.
А для 682622976 это значение равно 666624.

Теперь другой фрагмент, коих немало
Запись в индексе $I30 в файле 0x1bb10 указывает на файл 0x89032,
который расположен вне MFT.
Опять же, если перевести в десятичные, то можно прочесть о том, что индексная запись в файле 113424 указывает на файл 561202, который размещён за пределами MFT.
Что, в принципе справедливо т.к. 561202 > 559868; и можно предположить что чекдиск кастрировал MFT.

temp9285

Цитата:

Насколько понял - папки пустые или в них мало (мелких?) файлов?
Если учесть что дата MFT - октябрь 2014 года, не удивлюсь ели подтвердится что бывший хозяин форматнул раздел.

Не знаю, вроде не пустые, в некоторых есть подпапки и файлы.
вот, развернул одну для примера.

http://s008.radikal.ru/i304/1602/19/db18b2e774b3.jpg

Так же приведу ниже скрин, что нашел hetman(там есть папка lost files, где также куча папок и файлов.

http://s019.radikal.ru/i631/1602/c1/0d24390a44e5.jpg

а если диск таки был отформатирован, уже невозможно восстановить таблицу и бут(файлы как я понимаю на месте, а потерянные из-за повреждения таблицы)?

upd: скрины перепутаны местами

avtandil33
Ещё один фрагмент
Удаление элемента Arab1-A.wav из индекса $I30 файла 559770.
Такой же есть и в отношении 559771, а может и ещё других.
Теперь смотри часть найденных фрагментов MFT http://tau.rghost.ru/6MsM7VcS4/image.png
Фиолеовы выделено уже знакомое число записей.
Но сейчас важен выделенный красным. Это фрагмент начинающийся с записи 556380 и длиной 3488 записи. Но печалька в значении в скобочке -3139 - это число отсутствующих записей. Может туда что то упало не то, может они серьёзно повреждены, но их как бы нет (даже с каким то сдвигом).
Поэтому не удивительно что нет чего то.
И неудивительно что из индексов каталогов удалялась информация об отсутствующих файлах.


Цитата:

Что интересно у них у всех стоит чекдисковская метка - файл 113424

Посмотри что в этой и других часто упоминаемых записях и станет чуть понятнее.

PS. В результатах поиска есть немало крупных неидентифицированных фрагментов, в которых немало и удалённых записей. Возможно что среди них и есть нужные тебе, но это надо расскапывать.

PPS. Совсем забыл про
Цитата:

Я не думаю, что тут вмешались сторонние системы - я записывал данные под семеркой, потом просто несколько раз втыкал этот диск в виртуальную винду на маке, но это не портило файлы. А испортил как раз чекдиск, который я опять-таки запускал на семерке.

Даже при простом подключении к работающей системе происходят записи в ФС. Кстати, маковские ОС очень недурно гадят несколькими служебными папками (название не помню). И вообще, в неопределённый то момент может произойти какое то стечение обстоятельств, которое приведёт к глюку. Причём это могут быть не зависящие от пользователя.
И если произошло какое то наложение мусора в область MFT, то чекдиск можно обвинить, но наверное в обрезке размера файла, но не в корректировке индексов об отсутствующих записях. Хотя, если вспомнить скандиск или NDD, то там было более грамотно - сообщение об ошибках, запрос на исправление, создание файла отката изменений.
И ещё один момент. Учитывая сильную фрагментацию MFT, можно быть уверенным в том что и сами данные сильно фрагментированы; что нередко является следствием чрезмерной заполненности раздела. Насколько был заполнен раздел?


Добавлено:
acrid2
Я не в курсе как устроен раздел восстановления соньки, но обычно есть несколько огромных wim-файлов.
Есть что то подобное?

Цитата:

а если диск таки был отформатирован, уже невозможно восстановить таблицу

Учитывая значение начальных кластеров MFT и зеркала, число записей равное 256 - форматирование делалось вистой или более новой виндой. Соответственно - нет содержимого такого числа записей бывших ранее. А это достаточно много когда речь идёт о восстановлении функционал раздела восстановления, который то и без одного файла может не заработать.
Если интересно, сделай Поиск NTFS на учаcтке этого раздела и выложи лог поиска.
ИМХО, не стоит использовать без надобности бэта версии.

И в условиях поиска убери галку с RAW и прочего, что не относится к NTFS.

Цитата:

Если интересно, сделай Поиск NTFS на учаcтке этого раздела и выложи лог поиска.
ИМХО, не стоит использовать без надобности бэта версии.

И в условиях поиска убери галку с RAW и прочего, что не относится к NTFS.

Вот это, наверное, не есть хорошо?

http://s018.radikal.ru/i514/1602/a7/808980ff4dbd.jpg

лог

acrid2
Пробовал открыть результаты поиска?
По логу виден фрагмент размером в 2304 записи.

Цитата:

По логу виден фрагмент размером в 2304 записи.

Да, пробовал, а на что обращать внимание, на размер?

что отражает объем "записи" -это размер, кол-во файлов или что?

Добавлено:
Искал по разделу поиском, параметры и результат на скрине.

http://s016.radikal.ru/i334/1602/07/714fb1d2024b.jpg

Добавлено:
вообще, все что нашел hetman и что я скопировал на диск - это 2,8Gb. 2,72gb из них в папке "$ lost and found" больших фалов а-ля *.wim нет

Добавлено:
вообщем ладно, спасибо Вам за помощь, уже даже мне понятно, что там ничего не восстановить...там основных файлов нет, а все что осталось какой-то мусор..

temp9285


Цитата:

Ещё один фрагмент
Удаление элемента Arab1-A.wav из индекса $I30 файла 559770.
Такой же есть и в отношении 559771, а может и ещё других.
Теперь смотри часть найденных фрагментов MFT http://tau.rghost.ru/6MsM7VcS4/image.png
Фиолеовы выделено уже знакомое число записей.
Но сейчас важен выделенный красным. Это фрагмент начинающийся с записи 556380 и длиной 3488 записи. Но печалька в значении в скобочке -3139 - это число отсутствующих записей. Может туда что то упало не то, может они серьёзно повреждены, но их как бы нет (даже с каким то сдвигом).
Поэтому не удивительно что нет чего то.
И неудивительно что из индексов каталогов удалялась информация об отсутствующих файлах.


Цитата:
Что интересно у них у всех стоит чекдисковская метка - файл 113424

Посмотри что в этой и других часто упоминаемых записях и станет чуть понятнее.

Посмотрел - не стало Объяснишь ?



Цитата:

PS. В результатах поиска есть немало крупных неидентифицированных фрагментов, в которых немало и удалённых записей. Возможно что среди них и есть нужные тебе, но это надо расскапывать.

А это реально покопать или уже в морг ?


Цитата:

PPS. Совсем забыл про
Цитата:
Я не думаю, что тут вмешались сторонние системы - я записывал данные под семеркой, потом просто несколько раз втыкал этот диск в виртуальную винду на маке, но это не портило файлы. А испортил как раз чекдиск, который я опять-таки запускал на семерке.

Даже при простом подключении к работающей системе происходят записи в ФС. Кстати, маковские ОС очень недурно гадят несколькими служебными папками (название не помню). И вообще, в неопределённый то момент может произойти какое то стечение обстоятельств, которое приведёт к глюку. Причём это могут быть не зависящие от пользователя.
И если произошло какое то наложение мусора в область MFT, то чекдиск можно обвинить, но наверное в обрезке размера файла, но не в корректировке индексов об отсутствующих записях. Хотя, если вспомнить скандиск или NDD, то там было более грамотно - сообщение об ошибках, запрос на исправление, создание файла отката изменений.
И ещё один момент. Учитывая сильную фрагментацию MFT, можно быть уверенным в том что и сами данные сильно фрагментированы; что нередко является следствием чрезмерной заполненности раздела. Насколько был заполнен раздел?

Где-то около полутора ТБ из двух. Причем ценной инфы где-то 500 гигов, порядка 1 ТБ есть и в копии. Там была вот еще какая особенность. Был один каталог Chartco, у которого внутри было порядка 2000 мелких файлов. В свое время подобный каталог мне убил флэшку, а искомый диск вис в маке при обращении к этой папке. Но я всю папку гневно удалил (даже мимо корзины), после чего диск стал нормально работать на маке и соответственно на виртуальной винде. А чекдиск был уже после этого процесса.

avtandil33

Цитата:

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

Не всё проявляется моментально, тем более там, где есть кэширование.
Банальный пример - если при работающей системе обнулить таблицу разделов, то ничео не случится. А после перезагрузки - банан.

Цитата:

Посмотрел - не стало Объяснишь ?

Видно и на скриншоте что это одна из твоих папок. Соответственно, упоминание удаление каких то записей за пределами MFT, относящихся к этой папке, означает упоминание о них и это место становится доступным для новой информации - в том числе и для изменяемой далее чекдиском.


Цитата:

А это реально покопать или уже в морг ?

Это зависит от тебя - захочешь ли ты искать названия, определять к чему это относится и далее определяться что делать.


acrid2
Ну что поделать. Хотя .... я не являюсь истиной в последней инстанции.
Может стоит всё таки разобраться в соответствующем месте и установить систему.
Например, беглый поиск привёл в https://community.sony.ru/t5/pk-i-aksessuary/poryadok-ustanovki-drayverov-vpcz13z9r-windows-7/td-p/1990060/page/4
Ну и ещё один совет - подумай о необходимости 0-го рэйда из четырёх SSD. Любо из них вылетит и аля-улю всему массиву.

[more] [more]. [/more] Да как я уже только не пробовал драйвера ставить и приложения, что там доступны...и так и сяк и наперекосяк... не работают fn хоть ты тресни...люди в сети пишут, что такое случается и на других ноутах(например hp), что нормально все работает только из рекавери... да и еще там что-то должно быть, кроме виндовых дров для fn клавиш, ведь они должны работать еще до загрузки винды, сразу после включения экрана грубо говоря(как, например на простейшем нетбуке acer aspire one, c которого я сейчас пишу), а хрен там...
Может эти дрова заточены под систему которая на ноуте в стоке стоит win 7 pro AO CIS and GE x16-96122...потому что при попытке накатить лицензионную винду с новой проблемой столкнулся, что ключ, который на наклейке только к такой сборке подойдет, а ее тоже хрен найдешь, с офф. сайта не скачаешь...пишут только к производителю обращаться...вот и вторая причина по которой рекавери необходим...

а теперь еще одна проблема нарисовалась, после моих манипуляций с удалением раздела и воостановлением из копии, не грузится винда теперь ) короче он бут не видит теперь вообще... видать тот что на 100мб виндовский был слеплен с рекавери но работал, а после разделения надо бы его сделать как-то ) как бы все вернуть теперь? dmde на том ноуте, грузить с загрузочной флешки, запускать dmde, а дальше что? [more] .[/more] [/more]

acrid2
Что касается установки винды и т.п., это уже. [more=оффтоп]В жизни всякие пакости встречаются, в том числе есть недоказанная инфа что предустановленная система очень сильно привязана к винту, но в заточку драйверов не верю. Ведь в этом случае не было бы смысла выкладывать их на сайте - по крайней мере без предупреждения. Да и дистрибутив скорей всего легко найти (вопрос легальности - это другой аспект) - обычно это OEM-ная версия.[/more]
Ну а что касается проблемы с загрузкой, то их как бы не должно быть из за того, что сделали потому что до изменений у тебя был один рабочий раздел и один без бутсектора, считай что его не было. На рабочем у тебя были необходимые для загрузки файлы и он активный. И это не должно было измениться.
Ну разве что в контейнере загрузки была запись о загрузке с восстановленного раздела, которая раньше просто не работала (и то это гипотетически). Если что, можешь загрузиться с чего то, что увидит твой рэйд полноценно (кстати, ещё одно из неудобств рэйдов) и удалить восстановленный раздел, можешь бутсектор затереть.
А для начала просто загрузись с дстрибутива и войди в режим восстановления - возможно что винда починит что нужно.

после изменений у меня стало три раздела: один не размеченный, как раз тот самый виндвый на 100мб(помечен черным), один с виндой(диск с и один на те самые 8 гб(рекавери), и бут при старте ноута он берет с него, вместо виндового на 100мб раздела...(это как я понимаю, возможно в корне ошибаюсь)
ведь я правильно понимаю, что для нормальной загрузки винды как раз и служит тот самый резервный раздел на 100мб и на нем хранится boot record и mft таблица? или mft для каждого раздела своя, а на 100мб только запись бут?

acrid2
Покажи текущее состояние разделов, ну или опиши как то более подробно.
Если ты правильно восстанавливал, у тебя должно быть всего два раздела - основной и рековери. Так оно и есть.
Даже если бы ты восстановил 100 меговый, то загрузка всё равно начинается со большого раздела, т.к. он активный (буковка А около типа 07).
MFT у каждого раздела своя.

temp9285


Цитата:

Цитата:
Посмотрел - не стало Объяснишь ?

Видно и на скриншоте что это одна из твоих папок. Соответственно, упоминание удаление каких то записей за пределами MFT, относящихся к этой папке, означает упоминание о них и это место становится доступным для новой информации - в том числе и для изменяемой далее чекдиском.

Пока не врубился. Тут где-то цифры надо из 16-ричной в 10-ричную переводить, чтобы номера получить ? А то не узнаю свою папку по скриншоту.



Цитата:

Цитата:
А это реально покопать или уже в морг ?

Это зависит от тебя - захочешь ли ты искать названия, определять к чему это относится и далее определяться что делать.

Дык русские же не сдаются ! Даже если не удастся полностью восстановить нужные данные,
не догоню, так хоть согреюсь, всяко опыта поприбавится...
Так что жду инструкций...

temp9285
посмотрите пож-та мой пост от 10 числа 00:32 самый нижний скриншот, там я показывал как винда видит разделы.

вот он http://s019.radikal.ru/i623/1602/11/b749e87455a2.jpg

как я вижу ситуацию.
предыдущий владелец, перед продажей наспех устанавливал винду(скорее всего и понятия не имея что такое рекавери) соответственно, перед установкой делал разбивку диска, как предлагала винда. винда под его присмотром установила свой mbr и сопутствующие файлы в раздел рекавери sony, отсюда их симбиоз, тем самым поломала мбр и уничтожила часть файлов(возможно вместе с mft)рекавери раздела Sony.
так вот, загрузочная запись для прежней конфигурации винды как раз и находилась в тех 100 мб( которые теперь не распределены) и в данный момент берется из раздела 8 гб( где полная разруха и нинаких упоминаний о нынешней винде ессно)
возможно(и скорее всего) у меня в голове примерно такая же ситуация как в mtf таблице раздела рекавери sony ))
что скажете, док?

Добавлено:
я вообще правильно понимаю для чего при установке виндой создается 100мб раздел(как я понимаю, там бут рекорд и другие системные файлы, необходимые для загрузки)??
Может я вас не понимаю как раз из-за неправильно представления о том как происходит загрузка...

Добавлено:
Вот, вычитал что 100 раздел нужен для BitLocker и создается он, когда при установке Windows разделы создаются заново, а если они уже были созданы ранее, то этот 100 не создается и загрузчик находится там же где система(в моем случае на С...
Но, раз у меня этот раздел присутствует значит мое предположение верно, и тот кто ставил винду создавал разделы заново при установке винды и этот 100 мб упал в раздел с рекавери, при этом потер его...только не пойму тогда, почему размер этого раздела был прежние 8(условно) + 100, вместо того, чтобы 100 + все остальное...

Добавлено:
дополню: сначала, он видимо додумался его отформатировать, раз менеджер разбиения винды не видел разделов при установке

Добавлено:
по поводу raid 0 - а какие варианты? потерять половину объема и raid1?

avtandil33

Цитата:

Тут где-то цифры надо из 16-ричной в 10-ричную переводить, чтобы номера получить ?

Конечно, если в логе чекдиска они в таком формате, то как без перевода в привычный вид?
У шестнадцатиричных в начале 0x

Цитата:

всяко опыта поприбавится... Так что жду инструкций...

Вряд ли по инструкциям он прибавится. Да и без повторений (осмысленных) быстро забудется.
Попробую написать, но не люблю я слишком долго описывать, а кратко сложновато.

acrid2
Давай не будем здесь углубляться в оффтоп.
Есть тема http://forum.ru-board.com/topic.cgi?forum=62&topic=18466#1 в которой описан механизм загрузки, и из которой можно понять что вставка раздела не должна влиять на начальную загрузку.
Ну и что касается рэйда0, то лучше пойми его структуру и к чему приводит потеря одного участника.
Обьём ты не потеряешь. если не будешь делать рэйд1 (смысл в нём?).

Цитата:

вставка раздела не должна влиять на начальную загрузку.

не должна, но повлияла...Я от ваших инструкций и шага в сторону не делал, теперь вот буду голову ломать как починить, ибо никогда не ставил винду на raid массив, там наверняка какие -нибудь нюансы всплывут, или нет? тогда мне проще все снести и заново винду накатить

[more=оффтоп]а смысл в рейд 0 есть, скорость hdd этого ноута гораздо выше, чем у десктопа, где одиночный ссд, а важную инфу я всегда храню на внешнем. Да и вариантов у меня никаких, не разбивать же на 4 маленьких харда, на который и винда то с дровами и сопутствующим софтом нормально не встанет( уменя на десктопе 128 и постоянно красный, хотя никогда на с: проги не ставлю, только самое-самое нужное, чем постоянно пользуюсь для скорости открытия.[/more]

avtandil33

Что касается твоих цифр и значений (ещё одно [more=добавление] В логе чекдиска смесь как десятичных, так и шестнадцатиричных - что то раньше не встречал такого, поэтому и спрашивал чем проверял.
Поэтому надо сопоставлять разные значения.
Например, в самом начале есть
Удаление элемента Gruz2016 из индекса $I30 файла 5.
Элемент индекса кодов объекта 0x19 указывает на файл 0x88a91,
но в этом файле отсутствует основной сегмент записи файла.
Файл 5 - корневой каталог тома. 0x88a91 = 559761
То есть, в индексе корневой папки имелась запись о каталоге Gruz2016, который имеет (имел) номер записи 559761, но с этой записью какие то проблемы.
Можешь посмотреть что сечас в ней, но боюсь что пустая.

Что касается записи 113423, то этот номер принадлежит папке 0Huis - и это видно на более раннем твоём скриншоте.
А вот что касается имени папки 113424, это тебе лучше понять по именам файлам, упоминаемых в контексте её. Потому как выдача номера записи зависит от систем (драйвера ФС) - опять же и от того как заполнена MFT. Можешь сам просто проверить скопировав на диск какую либо папку с кучкой файлов и подпапок и посмотрев потом номера их записей.
Как то так. [/more]к написанному ранее).

[more="Экспресс-методичка"]В архиве http://rghost.ru/6sMk5N2dt несколько скриншотов, которые будут фигурировать в написанном ниже.

Для примера я создал папку Metelkin, в которой создал пару файлов и подпапку. Номера записей и прочие цифры относятся к моему примеру - у тебя свои.
Как видно из скриншота 1, номер записи этой папки в MFT - 9678. Так же виден характерный для записи MFT заголовок в начале сектора и как выглядит имя в записи.
Скриншот 2 - индекс этой папки. Видно что прописаны имена папки и файлов и их номера записей. Так как обьектов мало, то индекс находится непосредственно в записи.
Скриншот 3 - 30-й атрибут, в котором видно имя папки и номер родительской папки.
Скриншот 4 - информация о родительской папке. Виден номер кластера, в котором находится начало индекса - 4720 и число кластеров (*).

На скриноте 1 - окно поиска по имени этой папки.
Примерно так тебе и надо искать места где будет встречаться нужное тебе имя (чувствительность к регистру необязательна).
Самое важно что при этом надо смотреть в чём фигурирует найденное имя.
Потому как имя может находиться в записи MFT, в индексах родительской папки (в том числе среди мусорных записей), может быть и в журнале файловой системы.
И чтобы определить это, надо смотреть содержимое сектора или секторов рядом. Как выглядит запись MFT уже показано.
А вот так выглядит индекс папки (скриншот 5) - на рисунке лишь две значимые строки:
- в начале первой видна характерная абревиатура индексной записи (INDX)
- ниже красной черты имя из шаблона поиска Вот здесь обрати внимание на номер кластера. Это второй кластер из списка родительской папки (смотри * ранее).
То есть не всегда достаточно смотреть только в текущем или соседнем секторе.

Вот так вот ищи, и смотри. Можешь сначала поискать в районе "отсуствующих" записей - те что ранее выделял красным. Начальный сектор этого диапазона виден слева.
Ну как, опыта прибавилось?
[/more]

acrid2
Ну так удали вставленный раздел и примени изменения.
Насчёт [more=рэйда]моё дело было лишь предупредить. Понятно что ты хранишь важное на другом носителе. Ну а ляжет система - как тогда будешь ставить? [/more]

Есть (или уже был?) Seagate ST3000DM001-1CH166 (Z1F2NPCK) на 3 ТБ. SATA, один том на весь объём, не RAID. Всего пару лет проработал.
Он уже несколько месяцев назад начал проявлять признаки "усталости", но я, дурак, всё тянул до последнего.
На днях диск просто отключился при работающей системе (Windows 7 SP1 x64). После перезагрузки он опять появлялся, но при копировании файлов вновь пропадал.
Я пробовал сделать копию тома на другой 3ТБ-диск при помощи Acronis True Image и Disk Director, операция прерывалась из-за наличия ошибок.
А сейчас уже даже в BIOS этот диск не видно.

SMART по состоянию незадолго до:


На диске около 1,5 ТБ данных (видео и субтитры). Очень не хочется всё это терять, пусть даже файлы окажутся повреждёнными. Можете что-то порекомендовать?

Добавлено:
Хм, попробовать контакты почистить?

Dukat
Не поможет ему уже ни какая чистка при стольких переназначенных секторах.
Маленькая надежда, если в запил еще не ушел, обмануть, заблокировав обработку ошибок и вычитать, что возможно, на комплексе.
А если уже пошел в запил, но еще не по всем головам, откусить пилящую голову и спасти мелкие файлы по живым головам где-то максимум размером до 150MB.
Большие, такие как фильмы, бес толку без всех головок спасать.

tomset

Цитата:

на комплексе

Т.е. на спец. оборудовании, я правильно понял? В домашних условиях уже ничего не выйдет?

[more] [more]
Добрый вечер!

Сегодня при просмотре фильма, внезапно все зависло и появился синий экран со след. надписью "На вашем ПК возникла проблема и его необходимо перезагрузить. Перезагрузка будет выполнена автоматически. при желании вы можете найти в Интернете информацию по этому коду ошибки: PAGE_FAULT_IN_NONPAGED_AREA
Система загружалась только в безопасном режиме. Когда разобрал системный блок, выяснилось, что отпал один из вентиляторов видеокарты. Возможно перегрелась. Снял видюху, переключился на встроенную.
Поставил новую систему, теперь грузится все нормально, но но кроме системного диска С, больше ничего нет, а винт 3 Тб. Что можно сделать не знаю. Раньше было C, D, E.
C - 120, D около 1200, E - 1500. Главное, что они были забиты и мне не хотелось бы их потерять.
Помню, что при первой установке Win7, года три назад, пользовался прогой Disk Uploader. Ей же и разбивал винчестер. Жалко очень, за три года много чего хорошего накопилось.
Прилагаю скриншоты и с нетерпением жду вопросов.
https://imageshack.com/i/pmFFQUIcp
https://imageshack.com/i/pmOhsra3p
https://imageshack.com/i/pnTJxnUhp
[/more] [/more]

speno112
Ситуация достаточно нетривиальная. И самое печально что нет точности всего что было и какая прога всё таки использовалась. И последнее очень путает карты тем, что неизвестно каким образом оверлей обеспечивал доступ к "недоступным" гигабайтам. И что делает ещё. Например, в таблице разделов видны нестандартные значения - в простой ситуации можно было бы списать на мусор или на шаловливые ручки, но не т уверенности что это артефакты используемой программы.
Ну и конечно же смущает несоответствие размеров разделов. Можно было бы понять недоступность 1500 гигового раздела, опять же, если он был в конце. Но откуда взялся 800 гиговый?

Несомненно, лучше всего прекратить доступ к диску чтобы исключить новые записи на него. И запускать в DMDE Поиск NTFS. По мере его прохождения сохраняй промежуточные результаты. Можешь выложить какой то из промежуточных логов (где то через час поиска). Когда поиск закончится, сохрани окончательный лог, выложи его и открывай тома с наибольшим числом соотвествий - смотри что там.
После открытия любого в меню выбери Разделы диск и сделай скриншот - выложи.
PS. Давай ссылки на сами изображения. И можешь выкладывать на rghost.ru

PPS. Не дождался на кибере "знатоков" или нашёлся кто то нормальный (не стоит его засвечивать) и посоветовал обратится сюда?

speno112

temp9285

Диск базовый походу, не GPT. Поменялись драйвера и возник новый порядок дисков.
Нужно ту прогу которую использовали для первой разметки по новой запустить, чтобы переназначила адреса дисков.

tomset
GPT тоже относятся к базовым.

Цитата:

Поменялись драйвера и возник новый порядок дисков.

И изменилась размерность разделов?
Впрочем, я написал про то, что лично мне неизвестно как вообще организуется работа с диском различными приблудами, обеспечивающими доступ к пространству >2Tb.
И у меня нет желания проверять это, тем более что не собираюсь покупать такие винты.
Но думается что всё таки дело в другом, или вообще о чём то умалчивается.
Хотя одной лишь кривой установки ХР может и хватило - об этом написано #20 в в теме.

Цитата:

GPT тоже относятся к базовым.

MBR я имел ввиду. )
Столкнулся как-то с Парагон. Разметил, все пучком, толи выдернул и вставил в другой разъем. Или новый диск подключил. И разметки нет, пока Парагон по новой не с инсталлируешь.