Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Hardware » Магнитные носители информации » Восстановление разделов и информации на HDD (часть 7)

Модерирует : Akam1, Dr_StandBy, Dekker

Akam1 (11-10-2015 05:48): http://forum.ru-board.com/topic.cgi?forum=84&topic=5006  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163

   

Akam1



Комса
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Восстановление разделов и информации на HDD
 
первая часть :: вторая часть :: третья часть:: четвертая часть :: пятая часть :: шестая часть


Внимание! Если у Вас возникли проблемы с доступом к информации на дисках большого объема (более 120 Гб) - пропала таблица разделов, система говорит, что нужно отформатировать диск и т.п., то сначала прочитайте эту ветку про LBA48.
 
Для операций с разделами на жестких дисках по-возможности используйте штатные средства ОС. Прежде, чем править разделы с помощью Acronis Partition Expert, Norton Partition Magic и им подобных программ, пробегите быстро по всем страницам всех частей этой темы и Вы увидите, что половина проблем из-за них! Если не хотите сами наступить на эти грабли, запомните несколько простых правил:
 
- перед использованием программ типа Partition Magic всегда сохраняйте резервные копии важных данных
- не забывайте проверять диски на ошибки и дефрагментировать их (может помочь позже, при восстановлении данных)
- не пытайтесь изменять разделы на дисках с ошибками или на которых имеются сбойные блоки
- на время правки разделов постарайтесь обеспечить бесперебойную работу компьютера
- никогда не прерывайте процесс изменения разделов, если он уже начался
- не проводите операций по изменению разделов на дисках забитых до отказа, т.к. это значительно увеличивает продолжительность таких операций, а следовательно и риск возникновения сбоев
 
Прочтите и передайте другим, которые заходят сюда, когда уже слишком поздно...

 
То же самое касается программ ScanDisk и CHKDSK, автоматически проверяющих диски при загрузке системы. В случае серьезных сбоев они ничем помочь не смогут, но навредить могут изрядно. Поэтому всегда отключайте эти утилиты из автозапуска и выполняйте проверку дисков только вручную, периодически, когда уверены, что серьезных проблем на диске нет. Как их отключить написано здесь (на английском)

  • Общие рекомендации по самостоятельному восстановлению данных
     
  • Хороший совет по восстановлению, когда не уверен в своих знаниях
     
  • Список программ для восстановления информации
     
  • Статьи о восстановлении данных и жестких дисках
     
  • Восстановление данных из .chk файлов
    Обращаясь в тему за помощью, обязательно укажите информацию о диске: тип, емкость, способ подключения, информацию о разделах, SMART винта из MHDD / Victoria / HDDScan, наименование и мощность БП, возраст БП, результаты MemTest86, версию ОС и сервис-пака, а также обстоятельства краха - честное слово, толковым запросам и отвечать приятно. Здесь телепатов нет...
     

    Важно! Инструкция по чистке контактов на плате HDD


  • Всего записей: 26185 | Зарегистр. 20-04-2006 | Отправлено: 08:17 04-09-2013 | Исправлено: alexgr, 19:52 07-10-2014
    alexul



    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    спасибо бро что просвятил, по сигнатурам часть инфы вроде находит.

    Всего записей: 41 | Зарегистр. 22-12-2005 | Отправлено: 21:46 10-11-2014
    9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    бро

    А по русски нельзя?

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 21:50 10-11-2014
    alexul



    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    спасибо Россиянен
     
    Добавлено:
    вот хорошо написано про поиск со смещением ручками:

    Цитата:
     
    Практический пример определения смещения файлов в NTFS (определение виртуального начального сектора раздела).  
     
    Итак, что нам нужно.  
    1. Дисковый редактор WinHex (в примере использована версия 15.0 SR-2).  
    2. Документация Linux NTFS (легко найти в сети), далее [1].  
    3. Авторекаверилка R-Studio (в примере версия 4.0 Demo).  
    4. Моск Smile.  
     
    Алгоритм поиска смещения.  
    1. Выбираем реперный файл. Как уже заметили выше, в качестве такого файла удобно использовать документацию от программы. Вы должны точно знать, что этот файл есть на восстанавливаемом разделе, и у Вас должна быть его точная «здоровая» копия. Файл должен быть размером не менее ~1 КБ (чтобы не оказался резидентным). Я выбрал файл ReadMeRu.txt из каталога редактора DMDE.  
    2. Ищем файловую запись реперного файла. Для этого запускаем WinHex, открываем пострадавший физический диск. Нажимаем Ctrl+F, вводим имя файла ReadMeRu.txt (с расширением), Unicode, Search: Down, чекбоксы оставить неотмеченными, ОК (искать будет долго). Найденные секторы надо проверить на соответствие Файловой записи MFT ([1], п. 4.11), причем запись должна быть используемой (два байта по смещению 0x16 байт от начала записи должны быть 01 00). В моем случае первой нашлась запись другого файла: имя совпадает, но файл из другого каталога – у меня несколько версий DMDE (продолжение поиска дало желанный результат). Я легко определил, что файл не тот, потому что опыт проводился на живой файловой системе… Если ФС повреждена, правильно найти файл подобным образом будет проблематично, т. к. могут быть имена с одинаковым именем в разных каталогах, не говоря уже о других проблемах. Поэтому рационально использовать NTFS-сканер типа того, что есть в R-Studio, но я там не нашел возможности посмотреть начальный сектор файловой записи для выбранного файла. Есть еще мой Media Workshop, но он еще не доделан, хотя сканер уже давно функциклирует (выкладывать в сеть недоделку нет желания). В общем, тут остается неприятный момент с одинаковыми именами в разных каталогах.  
    3. Ищем содержимое реперного файла. Для этого открываем «живой» экземпляр реперного файла в WinHex, выделяем мышой первую строку, затем меню Edit – Copy block – Hex values (в случае других типов файлов первая строка может не прокатить – там зачастую заголовок, который одинаков для всех файлов такого типа). Теперь открываем проблемный физический диск в WinHex, Alt+Ctrl+X – окно поиска Hex значений. Вставляем искомые значения Ctrl+V, Search: Down, Cond: offset mod 512 = 0, остальные чекбоксы не отмечены, ОК (искать будет долго). Итак, я нашел начало файла, я вижу текст Readme от DMDE. Но я не знаю, от какой версии. Начал искать в браузере WinHex и обнаружил, что это Readme из каталога DMDE, расположенного в «Program Files\DMDE», а не в «Storage\Programs\DMDE\DMDE Win GUI», где я вначале нашел реперный файл. Т. е. опять проблема версий.  
     
    Лирическое отступление  
    Очевидно, что в моем случае реперный файл выбран неудачно. ИМХО нужен текстовый файл, который имеется на диске в одном экземпляре. Я попробовал на другом ReadMe – от AsmEdit, содержимое нашел правильно с первого раза (примерно в 10% от начала раздела объемом 61 ГБ), но с файловой записью возникли конкретные трудности, потому как имя файла Readme.txt есть и у других программ. В общем, если имя у файла распространенное, нужно искать файловую запись по реконструированной структуре в NTFS-сканере, который может показать для выбранного файла номер начального сектора. Следующим кандидатом стал файл Filemon.hlp (не текстовый) от программы FileMon, поиск содержимого осуществлялся по нескольким первым строкам hex-значений, поиск файловой записи – как обычно, только по имени. Поиск файловой записи дал индексную запись (INDX, [1], п. 4.16), это было очевидно и проблемы не создало. Продолжение поиска дало правильный сектор! Поиск содержимого дал правильный сектор с первого раза. Так что правильный выбор реперного файла имеет очень существенное значение.  
     
    4. Определение смещения начала реперного файла по ФС. Смещение начала файла от начала раздела в NTFS определяется как FromCls*ClsSct, где FromCls – начальный кластер файла, ClsSct – количество секторов на кластер. Размер кластера NTFS обычно 8 секторов. Теперь наша задача – найти номер начального кластера. Это несложно сделать в WinHex. Переходим к найденной файловой записи реперного файла ([1], п. 4.11). По смещению 0x14 байт от начала записи смотрим смещение начала списка атрибутов, обычно это 0x38 байт. Переходим по этому смещению и видим начало первого атрибута. В начале заголовка каждого атрибута два четырехбайтовых поля, расположенных последовательно: идентификатор типа атрибута и размер атрибута в файловой записи. Первый атрибут обычно имеет тип 0x10 (STANDARD_INFORMATION), на диске это выглядит как 10 00 00 00 48 00 00 00 (не забываем, что в каждом поле нужно инвертировать последовательность байт, т. е. размер атрибута 0x48 байт, а не 0x48000000). Размеры атрибутов одного типа могут быть различны, 0x48 дано для примера. Атрибуты в файловой записи расположены последовательно, нам нужно найти атрибут с идентификатором 0x80 (DATA). Т.к. размеры атрибутов указаны, мы просто переходим на размер атрибута и оказываемся в начале следующего атрибута. В WinHex Вы можете использовать окно Alt+G (Bytes, Hexadecimal, Current Position) для перемещения по цепочке атрибутов (обычно она включает атрибуты с типами 0x10, 0x30, 0x80; тех что с типом 0x30 может быть две штуки). Итак, вы в начале атрибута 0x80 DATA. Этот атрибут у Вашего реперного файла должен быть нерезидентным (мы специально искали файл не менее килобайта). В таком случае смещаемся от его начала на 0x20 байт и видим смещение списка экстентов, в большинстве случаев оно равно 0x40 байт. Смещаемся от начала атрибута DATA на 0x40 байт – мы в начале списка экстентов (ранлиста). Ранлист – это последовательность структур, указывающая размещение файла. Нас будет интересовать только первый экстент. Сейчас курсор в первом байте ранлиста. Посмотрите на этот байт. Его первая цифра означает количество байт поля смещения экстента, вторая цифра – количество байт поля размера экстента. Далее расположено поле размера экстента, за ним – поле смещения экстента. Например, в моем файле ранлист такой 31 - 04 - 81 2F 32 - 00. Видно, что под размер экстента отведен один байт, под смещение – три байта, размер равен 4 кластерам, а смещение 0x322F81 кластерам (не забываем перевертывать байты). После первого экстента расположен байт 00, он замыкает ранлист (если экстентов несколько, в этом байте начнется следующий экстент, и его смещение задается относительно начала предыдущего экстента). Итак, мы нашли смещение начала файла – это 0x322F81 (3293057) кластер, или 26311688 сектор от начала раздела при размере кластера 8 секторов (будьте внимательны, у Вас может быть другой размер кластера, например встречаются односекторые кластеры после преобразования FAT => NTFS).  
    5. Определение виртуального начального сектора раздела. Переходим в начало содержимого файла, которое мы нашли ранее. Смотрим номер сектора. Вычитаем из номера сектора смещение реперного файла, рассчитанное по ранлисту (в примере это 26311688), результат – виртуальный начальный сектор раздела, т. е. тот сектор, в котором должен был начинаться раздел для данной файловой системы (не стоит искать там бутсектор). Результат достигнут. После перемещения на 26311688 секторов от начала содержимого файла я наблюдаю на экране бутсектор раздела (эксперимент проведен на живой ФС).  
     
    Такую процедуру надо повторить для нескольких файлов, чтобы более/менее точно определить смещение. Если смещений несколько, как было отмечено выше, поиск этих смещений гораздо сложнее, у меня нет идей, как это можно сделать простым путем.  
     

    первоисточник:
    http://www.ihdd.ru/forum/kak-i-chem-uznat-smeschenie-vosstanavlivaemyh-failov-t7507.html

    Всего записей: 41 | Зарегистр. 22-12-2005 | Отправлено: 08:48 11-11-2014
    Tau_0

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    alexul

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

    Переходите ко второму этстенту/data-run и видите, что там что угодно, но только не ASCI код чего-то вразумительного. И как тут быть...???...

    Всего записей: 1236 | Зарегистр. 26-03-2010 | Отправлено: 11:04 12-11-2014
    9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    alexul
    Молодец что сам нашёл, действительно хорошее описание.
    Но только надо учесть один момент, о котором я писал ранее - то, что смещений может быть несколько.
    То есть, хххх файлов смещёно на zzz кластеров, а yyyyyyy на другое количество. И это для варианта когда поиск делался бы после первого этапа.
    Впрочем, всегда есть шанс что именно ты везунчик и будет всего одно смещение, ну или два.
     
    Tau_0
    В случае УПД Акронис возможно всё, но вообще то логично делать передвижки целиком.

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 11:58 12-11-2014 | Исправлено: 9285, 11:59 12-11-2014
    Tau_0

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    9285
    Так ведь из-за того, что одни отрезки по одному смещению, а другие по другому или вообще затёрты, и возникают проблемы восстановления фрагментированных файлов в случае неудачного завершения работы  партмагоида...

    Всего записей: 1236 | Зарегистр. 26-03-2010 | Отправлено: 13:32 12-11-2014
    9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Tau_0
    Проблемы с восстановлением после работы с партмагоидом, могут быть связаны с (в том числе) разными смещениями самих файлов, или записей MFT но не фрагментов самих файлов.

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 18:07 12-11-2014
    Tau_0

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    9285
    Тебе бы следовало сначала понятие файла определить, а уже потом об конкретных атрибутах говорить...
    ЗЫ Собирался я в своё время этот вопрос задать  Antech (он мне тогда давно  в ворде своё эссе сбросил...), но я не успел --- слишком тогда я был зелен...

    Всего записей: 1236 | Зарегистр. 26-03-2010 | Отправлено: 18:52 12-11-2014
    zybex15

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Tau_0

    Цитата:
    ЗЫ Собирался я в своё время этот вопрос задать  Antech (он мне тогда давно  в ворде своё эссе сбросил...), но я не успел

    А почему он пропал, кстати? Простите за оффтоп.(

    Всего записей: 439 | Зарегистр. 29-06-2014 | Отправлено: 20:26 12-11-2014
    9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    zybex15
    Очень интересный вопрос. В своё время он ушёл на хобот, но потом внезапно перестал писать в темах. Лично мне неизвестно по какой причине, как и некоторым знакомым участникам. Надежда лишь на то, что у него всё нормально и ничего плохого не случилось.
    Tau_0
    Если ты хочешь попускать пузыри, то лучше сходи в твоё любимое болото и там, под крылышком вертухаев, сделай это. А здесь постарайся писать по делу, и крайне желательно читать написанное осмыслено.

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 20:52 12-11-2014
    zybex15

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    9285
    Да, тоже на это надеюсь...

    Всего записей: 439 | Зарегистр. 29-06-2014 | Отправлено: 21:25 12-11-2014
    Tau_0

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    9285

    Цитата:
    А здесь постарайся писать по делу, и крайне желательно читать написанное осмыслено.

    Да ради бога --- для шибко умных, разжую осмысленно…
    Когда акронис сдвигает левую границу раздела вправо, то прежде всего он обязан перенести отрезки файла и пересчитать их относительно нового начала тома. Так вот одни отрезки он перенести успел и пересчитал, а другие не успел.
     
    А файл (грубо говоря --- речь только о нерезидентных data...) есть отобрахение VCN в LCN.
    Тогда часть файла будет посчитана относительно нового начала раздела/тома, а часть относительно старого начала. Это при условии, что данные не перекрыты…
    Так я понимаю одну из неприятностей партмагоидного смещения…
     
    ЗЫ Ты на зоне немало пызырей пустил, но потоп в том болоте так, что даже пузырей не осталось…  

    Всего записей: 1236 | Зарегистр. 26-03-2010 | Отправлено: 01:50 13-11-2014
    9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Tau_0
    Читай написанное мною выше.

    Цитата:
    В случае УПД Акронис возможно всё, но вообще то логично делать передвижки целиком.

    И учитывая твою любовь гордиться своей программерской "кровью", я бы ни разуу не удивился если бы узнал что ты один из разработчиков этого УПД. Потому как столько дури там и она, как я понимаю, принципиально не убирается. Всё в твоём стиле, который в народе называется "отморожу уши назло маме".
    У меня "кровь" обычного юзера, но знающего об устройстве NTFS чуть больше среднего. Тем не менее я примерно представляю как она устроена, её возможности и могу представлять как делать подобные (и не только) передвижки с минимальным риском проблем с данными.
    Давай рассмотрим твой пример передвижки начала раздела вправо. Естественно, часть данных, находится в начале раздела. В таком случае вполне логично переместить их в ту часть раздела, которая будет впоследствии задействована текущим. При этом файл, который ранее был фрагментирован может одновременно "склеиваться"; но главное его координаты заносятся относительно старого начала раздела. И при всём этом вполне реально задействовать и возможность журналирования действий самой файловой системой, и конечно использовать алгоритмы перемещения в ней же - файл записывается в новую область, проверяется считываемость его в новом месте, делается запиь транзакции, меняются данные в записи MFT и других служебных файлах о новом местонахождении, освободившееся место помечается таковым. Какой либо сбой, завис и т.п. не приведёт к потере данных. Вроде бы как много и муторно, но ведь надёжно. Когда все необходимые перемещения сделаны, делается пересчёт MFT и перезапись бутсектора. Тут уж не знаю как это сделать побыстрее, а главное надёжне, но наверное пересчитать в уме, а потом сразу переписать $MFT и BR. Хотя можно в реалтайме переписывать каждую запись и пр.
    Мне думается что в акронисе всё это делается одновременно, причём в несколько потоков и в несколько смещений - последнее означает что раздел сначала сдвигается на один сдвиг, а потом переносится на другой (тому есть косвенные подтверждения). В таком случае действительно возможно всё.
     
    Теперь что касается неприятностей партмагоида. Ты реши хотя бы один (пусть даже простейший) случай с подобными срывами при перемещениях и тогда уже суди что там является главнее. Я же могу тебя заверить что различный смещения частей одного файла, если и есть в списке проблем, то где то в самом конце вереницы таковых.
     
    Ну и самое главное. Ты конечно же начнёшь традиционно усераться и винить мою предвзятось, но теперь почитай написанное Antech-ем и то, что ты написал по поводу его фразы.

    Цитата:
    Ранлист – это последовательность структур, указывающая размещение файла. Нас будет интересовать только первый экстент.
    То есть речь идёт лишь о начале файла и как быто, что в пределах одной записи нет разных смещений. Впрочем и про разные смещения гуру написал, хотя я думаю что под таковыми он скорей подразумевал вариант не записей одного файла а разных - как раз таки такое очень часто и густо имеется при подобных превращениях. И именно поэтому в DMDE файлы одного бывшего тома нередко восстанавливаются с разных найденных томов (с разными началами разделов).
     
    PS. На болоте газа выше крыши. Недавняя тема в которой договорились до того что гемоблок винта герметичен потому что он гермо, и там вообще мембрана выравнивающая давление это как полёт во времена 20мб винтов. Причём упор на гермо делался тем, кто как бы по специфики своей работы физически разбирает винты. Так что маразма там (кроме озвученного) - мама не горюй.

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 02:41 13-11-2014
    Tau_0

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    9285

    Цитата:
    Вроде бы как много и муторно, но ведь надёжно.

    Красиво  ты Нью-Васюки разрисовал…
     
    Но только так при всём желании не реализовать…
    Как работает драйвер NTFS рассказано в самых общих чертах, а Microsoft глубоко прикрыла эту информацию. А для этого горы информации нужны. Поэтому организовать тесное взаимодействие с Windows невозможно..
     
    Конечно я непричастен к акронису, но знаю, что он построен на базе NTFS драйвера Linux. Разработчики коего убили много сил и времени, но всё же его сумели создать. А насколько он соответствует спецификациям Microsoft не знает никто.
     
    Напомню, что отрезки следуют враскорячку.  
    См. КартинкуСсылка c иллюстрацией отображения VCN ===>LCN  
     
    Тут не до того, чтобы при переносе отрезки дефрагментировать, --- дай Бох еще дальше не подробить, когда свободного места не так и  много…
     
    Я думаю, что файл находится и относительно старого и относительно нового раздела потому, что он перенесен в новое место, но и на старом местоположении не перекрыт/затёрт… Фактически он пока цел  в двух местоположениях…

    Всего записей: 1236 | Зарегистр. 26-03-2010 | Отправлено: 09:22 13-11-2014 | Исправлено: Tau_0, 09:27 13-11-2014
    9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Tau_0

    Цитата:
    Но только так при всём желании не реализовать…

    Есть обоснования этого, или лишь бы попытаться оправдаться? Я не вижу препятствий для этого, в том числе и через сторонний драйвер. И если бы такое не было возможно, то по определению, сторонние драйверы позволяли бы работать с NTFS лишь на чтение - что собственно и было на начальной стадии.

    Цитата:
    c иллюстрацией отображения VCN ===>LCN  

    Я знаю твою любовь к заумным картинкам, копипастам и множественным расчётам. Но они традиционно ни о чём? Или к чему ты её показал?
     

    Цитата:
    Я думаю, что файл находится и относительно старого и относительно нового раздела потому, что он перенесен в новое место, но и на старом местоположении не перекрыт/затёрт… Фактически он пока цел  в двух местоположениях…

    Во первых, речь шла не об одном файле а о разных файлах одного тома. Хотя можно сказать и об одном, но в таком случае в одном томе он будет полноценный, в другом или пустышка или мусор.
    Опять же, не верующий мне может спросить автора программы. Но если неверующий подумает, то вспомнит что DMDE не работает с сигнатурами и самими файлами и информацию об их положении может брать из записей MFT и индексов (насколько я понимаю).
    А то, о чём пишешь ты может быть (хотя не уверен в этом) при восстановлении по сигнатурам.

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 10:38 13-11-2014 | Исправлено: 9285, 10:39 13-11-2014
    Tau_0

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    9285

    Цитата:
    DMDE не работает с сигнатурами и самими файлами и информацию об их положении может брать из записей MFT  

    Может и такое быть, что обломки старой MFT сохранились, об этом и без твоего ответа задним  умом после своего поста подумал...
     
    ЗЫ А написал я свои посты только потому, что alexul дал ссылку на статью  Antech, к которому у меня накопились вопросы...  Вот я  и пытаюсь, как умею, эту статью и рядом лежащие вопросы обсудить. Ты уж не обессудь...  

    Всего записей: 1236 | Зарегистр. 26-03-2010 | Отправлено: 11:09 13-11-2014
    9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Tau_0

    Цитата:
    Может и такое быть, что обломки старой MFT сохранились, об этом и без твоего ответа задним  умом после своего поста подумал...


    Цитата:
    Вот я  и пытаюсь, как умею, эту статью и рядом лежащие вопросы обсудить.

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

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 11:59 13-11-2014
    Tau_0

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    9285

    Цитата:
    Обсуждать можно, но к чему выдумывать несуществующую проблему?

    Да вроде как проблема существующая... --- Нефрагментированные файлы DMDE выбирает и копирует нормльно, а фрагментированные не всегда...

    Всего записей: 1236 | Зарегистр. 26-03-2010 | Отправлено: 22:34 13-11-2014
    9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Tau_0

    Цитата:
    Нефрагментированные файлы DMDE выбирает и копирует нормльно, а фрагментированные не всегда...

    Сам придумал или есть тому подтверждения? И то, что это происходит в неломанных версиях?

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 08:39 14-11-2014
    viking4



    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Приветствую гуру форума. Нужна помощь в восстановление баз outlook 2007 *.pst после форматирования раздела, пересоздания мбр и записи 300 мб инфы. Файл размером 1 гб. Папку с базами видит, archive.pst размером 2гб видит, а outlook.pst размером 1 гб нет. Перепробовал:
    \R-Studio.v7.5., Restorer Ultimate, unformat, Ontrack.EasyRecovery.Professional.v6.22,
    самый эффект Hetman Partition Recovery. И RAw и восст mft, ниче не помогло(
    Большая просьба помочь, письма очень важные от опполчения ДНР, копии нету

    Всего записей: 42 | Зарегистр. 19-10-2005 | Отправлено: 11:15 15-11-2014
       

    Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163

    Компьютерный форум Ru.Board » Hardware » Магнитные носители информации » Восстановление разделов и информации на HDD (часть 7)
    Akam1 (11-10-2015 05:48): http://forum.ru-board.com/topic.cgi?forum=84&topic=5006


    Реклама на форуме Ru.Board.

    Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
    Modified by Ru.Board
    © Ru.Board 2000-2018

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru