Ru-Board.club
← Вернуться в раздел «Магнитные носители информации»

» Магнитный флейм

Автор: alexyc
Дата сообщения: 15.09.2015 02:00
Вопрос к "трактористам"...с точки зрения абсолютного дилетанта в ДР.Задан-не мной,мой ответ вопрошающего не удолетворяет.

Время копирования явно(?) указывает,что поверхность диска повреждена. Что в ней можно вычитывать,cудя по скорости,тратя тучу доноров?Вопрос не о принципах работы трактора(как он вычитывает нужное,о его прыжках и т д и т п)/насколько он единственный и незаменимый,а о смысле сего действа-что можно вычитать в поврежденных секторах?
Автор: igor_me
Дата сообщения: 15.09.2015 02:21

Цитата:
что можно вычитать в поврежденных секторах?

Я не тракторист, но предположу Думаю, что вычитывают они так всё что МЕЖДУ повреждёнными секторами Меня лично такая метода тоже смущает и вводит в ступор. Ибо ТАКИМИ усилиями и время- и деньгозатратами (на электричество и софт) и за ту цену это может понадобится либо жителям Москвы (и возможно Питера), либо очень большим и богатым компаниям, типа той, чьё название начинается на ГАЗ, а заканчивается на ПРОМ В моей практике было несколько случаев, когда я говорил своим клиентам, которые говорили, что у них там очень ценные фотки и т.п., что мол "вот кое-что удалось достать, частично повреждённое, кое-что не читается совсем. Скорее всего - дохнут головы, надо в DR нести". как только я им называл, что это у них стоит от полутора тысяч и выше - все сразу забивали и "достань, что возможно - остальное пофиг, переживём". Может я чего не понимаю. Говорят ведь - Москва - другая планета
Чисто моё мнение, никому не навязываю...
Автор: Turkish88
Дата сообщения: 15.09.2015 08:02
sandy_t
А что р-студия не ищет "черным" по незанятой карте?
Автор: 9285
Дата сообщения: 15.09.2015 08:25
tomset

Цитата:
Некогда мне в эти тонкости лезть.

Вооооот. Если кто то не знает тонкостей, то получается что веритна слово. И если разработчик допустит какой то глюк в алгогритмах, то не узнает что на самом деле битый файл был то целый.

Цитата:
В JPG длина всего файла есть.


Цитата:
Следовательно конец файла и его нарушение легко вычисляется.

Где, если это не корпоративная тайна. И если есть таковая, и маркер конца файла разве не логично использовать эти данные (*) при черновом поиске, а не выкачивать кучу хвостов?
(*) При этом контролировать наличие вкраплений других известных типов файлов?


Цитата:
Как же вы понять не можете, Нам почти не носят диски не с физическими проблемами. Их делают в основном сами клиенты или эникейщики.

Да это вы не можете понять (аналогию про грузовик уже упоминал), что речь не идёт о простых случаях.
Вернёмся к теме, которая указана в начале. Я не стал цитировать, но там же есть и
В такой ситуации удобно пользоваться Data Экстрактором.
Но дорогая штука.
Он по крайней мере проверит некоторые типы файлов, что они целые.
И их отдельно можно выделить в свои директории по типу.
JPG. DOС. XLS. ZIP и некоторые другие.
А все непроверенные свалить в другие директории.
Что потом сокращает время на ручную сортировку хороших и плохих файлов.

Всё то же самое делает, разве что кроме проверки целостности, та же R-studio и новая версия DMDE.
http://rghost.ru/6H87znPN4.view
Причём последняя делает это беззвозздмезно.
И ведь практика форумов показывает что и в более сложных ситуациях народ пилит диски ломанно-крэкнутыми вещами, пользоваться которыми (как вы написали) "ума не надо". А вы предлагаете им комплекс за немеряное число денег.


Цитата:
Много же ума не надо, чтобы запустить, например, R-студию или DMDE.

Большинство впервые садящихся за руль считает что водить авто элементрно. А потом мы слышим по ящику о катастрофах, да и в жизни видим во что это выливается. И так можно сказать о большинстве специальностей. И тут снова возвращаемся к "Я куплю коплекс и стану крутым восстановителем".

Turkish88
Насколько я знаю - нет, как и все остальные, популярные в темах на разных форумах, программы по восстановлению.
Опять же, чтобы использовать такую фичу надо быть уверенным в том, что данные о занятом пространстве верны. А как это можно проверить? Применительно к твоему случаю - чекдиском; но буквально недавно tomset утверждал что он (чекдиск конечно же ) не может дать 100% гарантию.

sandy_t
В ранее написаном уже есть ответы на заданные вопросы, поэтому сильно повторяться не буду.

Цитата:
другая утилита лучше справится с фрагментированными данными? Считай фрагментация равно потере данных в любом случае
Нет, но читай чуть выше - в процитированном смысле если и есть смыл покупать DE (он отдельно продаётся?), то лишь для контроля целостности.


Цитата:
Так накой мне использовать что-то другое, если то, что есть в комплексе устраивает?

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


Цитата:
Альтернатива, Вами предложенная - пусть клиент сам разбирается и проверяет, что живо, а что нет - это не серьезно. А если его результат не устроит?

Так они и проверяют.

igor_me

Цитата:
Говорят ведь - Москва - другая планета

Вот есть же люди понимающие реальность жизни (за пределами МКАД)
Хотя тут есть другой момент - работая с огромным числом убитых дисков может создаться впечатление что простых случаев не бывает.
Автор: tomset
Дата сообщения: 15.09.2015 11:47
9285


Цитата:
Если кто то не знает тонкостей, то получается что веритна слово. И если разработчик допустит какой то глюк в алгогритмах, то не узнает что на самом деле битый файл был то целый.

Не держите нас за дураков. Эти методы проверяются тысячами пользователей DE.
Хай на форуме АСИ поднимется - будь здоров, если такие неточности выясняются.
Я же пишу - не абсолютно всё, могут проверить методы. Нет в природе методов восстановления данных гарантирующих 100% результат.
Клиент часто счастлив, когда ему и половина восстанавливается. Это лучше чем ничего.

igor_me

Цитата:
Думаю, что вычитывают они так всё что МЕЖДУ повреждёнными секторами Меня лично такая метода тоже смущает и вводит в ступор.

Вы просто не вычитываете так, потому и не может знать, что получается.

Хард на одном сбойном секторе может висеть до нескольких минут.
А если хард зависает, то процесс его перезапуска может занимать и десятки минут.
Но среднее время окончания рассчитывается по фактически выполненной работе и остатку.
Пока не прочитаешь этот остаток. Прогнозировать что-то вообще бессмысленно. Считается ожидаемый остаток времени исходя из текущей ситуации.
А потом может оказаться, что несколько миллионов секторов хард пролетит мухой. И результат расчёта сразу порадует. И опять наткнется на трудночитаемое место и цифра ожидания превратится в годы.
Это нужно просто понимать, а не верить на слово всяким прогнозам, как цыганкам.

Чем больше всех читаю, тем больше вижу, что вы настолько далеки от темы восстановления данных. Просто катастрофа.
Не лучше чем самый далекий от компов пользователь.
Сплошная вера в чудо-сказки, существование чудо программ, тайных методик.
Дет сад!
DE обычный инструмент из многих, со своими достоинствами и недостатками.
В среде DR бизнеса, считается одним из лучших на сегодняшний день.
Результат будет прежде всего зависеть от опыта пользователя, который не пару раз восстановил данные, а делает это каждый день много лет.



Автор: 9285
Дата сообщения: 15.09.2015 12:15
tomset
Я правильно понял что размер jpg-файла является тайной?

Цитата:
Не держите нас за дураков.

Вас я за дураков не держу. Повторяя устало - вы слишком близко всё воспринимаете в свой адрес.
И явно обиделись.
Автор: tomset
Дата сообщения: 15.09.2015 12:58
9285

Цитата:
Я правильно понял что размер jpg-файла является тайной?

Скорее всего нет, раз Ася узнала.
Существует видимо документ какого-то комитета разрабатывающего формат JPG.
Ася его каким-то образом нашла.
Я не искал.

Я например выпал в осадок, когда узнал, что чтобы читать документы по стандарту ATA на сайте T13.org.
Нужно стать членом сообщества, и платить ежегодный взнос 1000$ за право получать доступ к документации.
А все потому что правительство США, отказалось финансировать этот проект из государственных средств.
C документацией JPG может быть такая же ситуация.
Автор: alexyc
Дата сообщения: 15.09.2015 12:59
igor_me

Цитата:
Думаю, что вычитывают они так всё что МЕЖДУ повреждёнными секторами

да любому юзеру понятно,что вычитывают читаемое.Никто так и не ответил на вопрос.

Цитата:
что можно вычитать в поврежденных секторах?

Перефразирую его по иному.
У юзера "пропало фсе"!!!.Пордергав проводки,"постучав по капоту",обос...в колесо" убедился,"что ничего не помогает".Бросился к эникейщику-"за пиво" оный натравил на диск все что "знает и умеет".Предположим,восстановил малую часть,не добив диск.Пользователь посмотрел-посмотрел-нет нужного.Побежал в ДР контору (предположим с действительно,професионалами) Диск начинает "крутиться" на тракторе.Все что можно-вычитано.Юзер получает список и НЕ находит,"того единственного файла",который оказывается "нужным уже вчера" Дальше пляски с донорами и вычитывание "того самого промежутка".В итоге,клиетн оплачивает доноров и ничего не получает,т к никто не ответил-ЧТО МОЖНО ВЫЧИТАТЬ в поврежденной поверхности. Толку от 47 г фоток,если нет "той самой",одной,без которой что 200 фоток восстановленных эникейщиком,что 47 г ДРпрофессионалом РАВНЫ по конечному результату,точнее,его отсуствии.Оплата труда несомненна,оплата доноров-????
Описано достаточно сумбурно.
Автор: tomset
Дата сообщения: 15.09.2015 13:11
alexyc
Ну это жизнь, ситуации бывают самые различные.
И тут уже только пользователь может решить, стоит ему платить за попытки или смириться с потерей.
Некоторые, лукавят, типа: плати - все спасем.
Я всегда говорю, что есть приблизительно такая-то вероятность спасти данные.
А фактически - не попробуешь, не узнаешь.
Автор: alexyc
Дата сообщения: 15.09.2015 13:22
tomset

Цитата:
Ну это жизнь, ситуации бывают самые различные.
И тут уже только пользователь может решить, стоит ему платить за попытки или смириться с потерей.

Да самая,что ни на есть обычная ситуация-по "закону подлости".Вопрос не в стоит, пытаться или нет-вопрос "тупо в лоб"-что можно вычитать в нечитаемом,тратя ресурсы на это.Или "фантастический" трактор способен "прыгнуть выше головы" и вычитать царапину,неважно какими затратами???Если же нет-для юзера "никогда" не будет иметь смысла тратить деньги на др,с успехом обойдясь помощью соседа-эникейщика.Максимум за что он согласится платить-восстановление данных специалистом ДР,но только того,что при приложении определенных трудов способен в теории выполнить эникейщик.Все же ваши "ухищрения"по "чтению полудохлой головой" и виртуозное владение трактором клиент не увидит смысла оплачивать
Автор: tomset
Дата сообщения: 15.09.2015 13:28
Так это зависит не от трактора, а от степени повреждения.
При многократных попытках можно иногда вычитать плохой сектор.
Иногда плохой сектор приходится на не важную часть информации в файле.
И то что там будут нули не будет ни как сказываться на целостности файла.
Все опять сводится к - не попробуешь, не узнаешь.
Я готов попробовать, когда это не связано с моими финансовыми затратами, или когда они незначительны.
Но допустим покупать донора за 12000 при средней цене работы 10000, я ни как не могу.
Так что клиент должен оплатить донор, если хочет чтобы я попробовал спасти его данные.
Автор: alexyc
Дата сообщения: 15.09.2015 13:31
tomset
Уже "ближе к телу"

Цитата:
При многократных попытках можно иногда вычитать плохой сектор.

Поясните,почему.Я понимаю так-дефект (дырка)-НЕТ информации в этом месте,она где-то на "стенках гермоблока".Если же нет дырки-почему не читается с первого раза.
Автор: tomset
Дата сообщения: 15.09.2015 13:39
alexyc
дефекты бывают собственно в трех случаях.
Переписано, Плохо записано и повреждена поверхность.
Переписанное восстановить невозможно - ни как.
Плохо записанное, или поврежденное, но не совсем "до стекла", может в какой-то момент прочитаться. Хард каждый раз читает сектор с некоторой погрешностью, порядка +/- 10%. Так что вероятность прочитать такой слабый сектор далеко не нулевая.
Иногда замена головок, позволяет вычитать таких слабаков, когда родные головы не могут.
Автор: alexyc
Дата сообщения: 15.09.2015 13:42
tomset
Вот сейчас вы написали именно то,что я не смог пояснить своими словами "соседу",т к считал что инфа,она или есть,или ее нет.Оказывается,есть третье состояние-она есть,но ..й ее получишь "обычным " способом

Цитата:
Плохо записанное, или поврежденное, но не совсем "до стекала", может в какой-то момент прочитаться. Хард каждый раз читает сектор с некоторой погрешностью, порядка +/- 10%. Так что вероятность прочитать такой слабый сектор далеко не нулевая
.
Я удолетворен ответом
Автор: tomset
Дата сообщения: 15.09.2015 13:49
И еще момент.
ECC гарантированно восстанавливает порядка 22-25 не прочитанных байт в секторе 512 в зависимости от версии.
Но в определённых ситуациях может восстановить до 170 неправильно прочитанных байт. Так что, как видите прочитать большинство и скорректировать некоторое количество непрочитанных байт далеко не нулевая.
Автор: 9285
Дата сообщения: 15.09.2015 15:11
tomset

Цитата:
Скорее всего нет, раз Ася узнала. Существует видимо документ какого-то комитета разрабатывающего формат  JPG. Ася его каким-то образом нашла.

Предлагаете и мне поверить на слово?
Что мешало бы им написать типа http://blog.acelab.ru/chernovoe-vosstanovlenie-ch2.html#more-176
И самое главное, использовать это значение при чернухе или создать какой то новый алгоритм типа описанного мною раньше и назвать серобуромалиновый?
Пока что, из http://blog.acelab.ru/wp-content/uploads/2014/07/черновое-по-GREP.png я вижу что размер найденного кратен размеру сектора. Что свидетельствует о неиспользовании того, что якобы известно. Да даже использование завершающей сигнатуры, которая точно известна.
Автор: tomset
Дата сообщения: 15.09.2015 16:27
9285
Ко мне какие претензии?
АСя пишет в блоге, что считает нужным и моего мнения не спрашивает.
Для примера выбрала наиболее простые форматы, чтобы понятней было, как это работает.

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



Цитата:
Пока что, из http://blog.acelab.ru/wp-content/uploads/2014/07/черновое-по-GREP.png я вижу что размер найденного кратен размеру сектора.

Как раз на непроверенных файлах, нет зеленой отметки.
Автор: 9285
Дата сообщения: 15.09.2015 16:49
tomset
К вам претензий нет, но и нет веры что в файле есть данные о размере.
Вот только не надо "аргументировать" по типу "ээээ. Ты меня уважаешь?"


Цитата:
Для чернового восстановления данных более важно знать размер в секторах.

Мне важно восстановить файл а не файл с хвостом. Это во времена СССР радовались ошмётку колбасы с верёвкой на конце и толстой (тяжелой) бумаге при взвешивании. Сейчас времена другие.
И если есть возможность отсечь лишнее, то почему бы и нет?


Цитата:
Как раз на непроверенных файлах, нет  зеленой отметки.

Ну это к блогописателям вопрос - я не знаю как там оно выглядит и чем "проверяется".
Тем более что в самом блоге http://blog.acelab.ru/chernovoe-vosstanovlenie-ch1.html можно прочитать про тепличные условия
файлы не были перезаписаны, они расположены непрерывно и имели известный и определяемый формат
И при таком коммунизме - такой конфуз?
Автор: tomset
Дата сообщения: 15.09.2015 17:07
9285
ну если бы смотрели внимательно и замечали детали, а не по верхам,
То на картинке с проверенными файлами все пучком:
http://blog.acelab.ru/wp-content/uploads/2014/08/raw-photo-task.png
Там же в метаданных (в окошке справа), есть структура JPG.
Есть еще редактор структур, который к обсуждаемому примеру не относится.
Там ваще все поля расписаны.

Обучать стараются на простых примерах.
Чтобы последнему чайнику было понятно.
А сложные случаи обычно обсуждаются в личке, на конкретных данных.
Замучаешься описывать сложный случай.
И вряд ли начинающий его поймет.
Автор: 9285
Дата сообщения: 15.09.2015 18:23
tomset

Цитата:
ну если бы смотрели внимательно и замечали детали, а не по верхам,   То на картинке с проверенными файлами все пучком

Но это же уже не черновой поиск.
Вы бы ещё привели скриншот поиска по целым файловым структурам.

Автор: tomset
Дата сообщения: 15.09.2015 18:42

Цитата:
Но это же уже не черновой поиск.


Это как раз и есть черновой поиск реализованный в DE.
Вверху все что нашел по структурам и по файлам с количеством объектов
Внизу содержимое категории объектов.
Есть даже возможность, отметить интересующие структуры и перенести их в виртуальный образ.
И гулять по нему, как по обычному диску, проверя, что хорошо. что плохо.
И сверяться с нижней вкладкой Нех или Структура, где будут показаны вид и ошибки.
Если хотите дам доступ по Tиму.
Подсунуть любой диск и сами по нему полазите.
Или образ свой возьмете.

Чтобы прочувствовать, так сказать.

DE RE не предлагаю, там еще более чумовая надстройка над DE.
Крышу снесет сразу.
Автор: Alex_Green
Дата сообщения: 15.09.2015 20:50
sandy_t

Цитата:
В DE парой кликов построена карта незанятого, черновое по этой карте - на выходе 47гб целых фоток.


В том же WinHex это можно сделать с таким же успехом.


Цитата:
Считай фрагментация равно потере данных в любом случае, поэтому и идет допущение об ее отсутствии.


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

igor_me

Цитата:
как только я им называл, что это у них стоит от полутора тысяч и выше - все сразу забивали и "достань, что возможно - остальное пофиг, переживём"


Как правило - аналогично.

tomset

Цитата:
Как же вы понять не можете, Нам почти не носят диски не с физическими проблемами.
Их делают в основном сами клиенты или эникейщики.
Много же ума не надо, чтобы запустить, например, R-студию или DMDE.


Ну как бы логические кейсы тоже делятся на простые и сложные, и разумеется простому эникейщику успешно делать сложные, просто не под силу.

Хотел вас спросить, а какой смысл вообще заниматься DR, если как вы пишете, расходы превышают доходы, ну или же в лучшем случае рентабельность колеблется около нуля?

9285


Цитата:
Я правильно понял что размер jpg-файла является тайной?


Насколько знаю, в самом файле эта длина нигде явно не выражена, как например в заголовке AVI файла (после сигнатуры RIFF следующие четыре байта описывают размер файла в байтах) но ведь действительно концовку файла легко определить по сигнатуре FF D9. Правда в JPEG файлах EXIF, она встречается также недалеко от начала файла, а в более упрощённом варианте JPEG файла JFIF, данная сигнатура только в самом конце файла и встречается. А вообще JPEG файлы довольно многие рекаверилки умеют восстанавливать корректно сигнатурным поиском. Гораздо веселей обстоит дело с AVI или MOV. Ну а с некоторыми видами MP4 так вообще до того весело, что практически ни одна рекаверилка не находит их сигнатурным поиском вообще.




Автор: tomset
Дата сообщения: 15.09.2015 21:22

Цитата:
Насколько знаю, в самом файле эта длина нигде явно не выражена,

Выражена.
Только не в явной виде, не в байтах. Преобразования надо делать.
Вот Ася пишет редактор структур. Пока еще в отладочном режиме. Не все фичи работают. Не показывает и не проверяет реальные данные, не привязывается к файлу.
https://yadi.sk/i/l3Cf8_JTj7PPM
Хотя нет, уже привязывается, нужные кнопки надо было найти.
Длина в словах + заголовок.
Автор: 9285
Дата сообщения: 16.09.2015 07:12
tomset
По поводу чернового потом отпишусь.
Удалёнкой можно воспользоваться, но не горю желанием.
А пока - http://rghost.ru/6bM9dLsbX
Если можно, в скриншотах показать как там будет по поводу целостности и каков результат.

Alex_Green

Цитата:
Правда в JPEG файлах EXIF, она встречается также недалеко от начала файла

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


Цитата:
А вообще JPEG файлы довольно многие рекаверилки умеют восстанавливать корректно сигнатурным поиском.

В таком случае там используется или поиск по алгоритму, описанным мною или используются данные самих файлов. Только, в отличие от DE (*) это неразделимо и является одним типом поиска - что вполне логично).
(*) у них в черновом два алгоритма: только по GREP и тогда конец файла не учитывается (не пойму почему), и с использованием данных файла.
Автор: tomset
Дата сообщения: 16.09.2015 18:29

Цитата:
у них в черновом два алгоритма

Не только.
Более гибкие настройки, чем в большинстве программ.
Только по текущему или общему справочнику сигнатур, или своим собственным.
По текущему справочнику сигнатур, но с учетом общего справочника, как раз для расчета длины и с проверкой по содержимому файла.
Искать в каждом секторе или по границам кластеров или блоков для других FS.
В зависимости от того, что известно об FS.
Создание по результатам чернового или обычного поиска карт расположения объектов в любых комбинациях, найденного, не найденного, проверенного, не проверенного или создавать карты по каким-то иным признакам.
На каждую карту можно делать уже свой черновой поиск.
И для всех вариантов чернового поиска результаты сохраняются в базе, можно в любой момент открыть интересующий вариант, а не сканировать по новой.
Так же и любую карту можно сохранить, чтобы потом открыть сразу, а не создавать по новой.
Что помогает в ситуации поиска фрагментов для фрагментированных файлов.

Группировать различные структуры, для поиска закономерностей, например, чередования в массивах или при развале трансляции.
Разбор этих структур, чтобы показать в удобочитаемом виде.
Например, показать сколько записей MFT идут подряд.
Файлы контейнеры, типа docx, ищутся по анализу структуры, а не просто по сигнатурам.
Автор: 9285
Дата сообщения: 16.09.2015 21:00
tomset

Цитата:
В зависимости от того, что известно об FS.


Цитата:
Например, показать сколько записей  MFT идут подряд.

Ну вообще то это уже не сигнатурный поиск, хотя идолу такое можно простить - не так ли.
Автор: tomset
Дата сообщения: 16.09.2015 21:12
9285
Все функции делаются не чтоб было. А только те которые реально нужны для работы.
Бывает конечно, что-то сделают, казалось бы нужное.
Но спустя какое-то время видят, что это на фиг ни кому не надо.
Или решается по другому.
То потом эти функции убирают или переделывают.
Т.е. комплекс не монолит, раз сделали и стриги бабло.
Он постоянно меняется, поэтому постоянная поддержка и обновления, непременное условие, успешной работы с ним.

В целом подходы к восстановлению данных совсем другие чем допустим в R-студио.
И если часто пользовался R-cтудио и подобными, то это потом долго мешает научиться пользоваться методами DE.

Кстати, есть еще одна вроде как фича, можно запустить десятки вариантов задачи DE одновременно или по очереди, хоть с одним образом, хоть с разными.
И пробовать разные подходы к одной задаче.
Все результаты на разных этапах в каждой задаче будут запоминаться в базе.
И если какой-то вариант дает лучшие результаты, продолжить работать уже с ним.
Автор: Turkish88
Дата сообщения: 17.09.2015 06:12
Может я неправильно понимаю занятое пространтсво? например 10Гб раздел был полный фоток. его отформатировали и записали фильм на 5гб. остальные 5гб фоток гдето все еще лежат. Травите на этот раздел 10гб р-студию, и она что не найдет в "незанятых" 5гб фоток?
Автор: 9285
Дата сообщения: 17.09.2015 12:06
tomset
Да это понятно - "грузовик" DE самый грузовикастый для перевозки пары кирпичей.
Turkish88
Всё зависит от конкретики. Предположим что раньше фотки были фрагментированы и если хотя бы один фрагмент (критичный) был в зоне куда запишется диск то, даже при наличии всех данных о фрагментах, получится куча битых фоток.
И в отношении R-studio есть некоторые сомнения - был замечен за некорректных восстановлением png-шек с "вкраплениями", в том числе в том что восстанавливал гигабайтные файлы.
Автор: Turkish88
Дата сообщения: 17.09.2015 14:38
9285
а DE прям все правильно найдет?

Страницы: 12345678910111213141516171819

Предыдущая тема: SATA II в SATA I


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.