Still Water

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Still Water » Мир Компьютеров » Как восстановить нечитающийся CD


Как восстановить нечитающийся CD

Сообщений 1 страница 4 из 4

1

Довольно интересная статья. Те, кто интересуются данной темой, могут найти в ней полезную для себя информацию.

Лазерные диски - не слишком-то надежные носители информации. Даже при бережном обращении с ними вы не застрахованы от появления царапин и загрязнения поверхности (порой диск фрезерует непосредственно сам привод и вы бессильны этому противостоять). Но даже вполне нормальный на вид диск может содержать внутренние дефекты, приводящие к его полной или частичной нечитаемости на штатных приводах. Особенно это актуально для CD-R/CD-RW дисков, качество изготовления которых все еще оставляет желать лучшего, а процесс записи сопряжен с появлением различного рода ошибок.

Однако даже при наличии физических разрушений поверхности лазерный диск может вполне нормально читаться за счет огромной избыточности хранящихся на нем данных, но затем, по мере разрастания дефектов, корректирующей способности кодов Рида-Соломона неожиданно перестает хватать, и диск безо всяких видимых причин отказывается читаться, а то и вовсе не опознается приводом.

К счастью, в подавляющем большинстве случаев хранимую на диске информацию все еще можно спасти, и эта статья рассказывает как.
Общие рекомендации по восстановлению

Не всякий не читающийся (нестабильно читающийся) диск - дефектный. Зачастую в этом виновен отнюдь не сам диск, а операционная система или привод. Прежде чем делать какие-либо заключения, попробуйте прочесть диск на всех доступных вам приводах, установленных на компьютерах девственно-чистой операционной системой. Многие приводы, даже вполне фирменные и дорогие (например, мой PHILIPS CD-RW 2400), после непродолжительной эксплуатации становятся крайне капризными и раздражительными, отказывая в чтении тем дискам, которые все остальные приводы читают безо всяких проблем.

От себя хочу добавить, что  Philips - кака. Мой сидюшник постоянно глючил с  чтением дисков, некоторые отказывался читать вообще. Это одна из причин, по которой мне пришлось покупать новый cd/dvd Rom.

А операционная система по мере обрастания свежим софтом склонна подхватывать различные глюки подчас проявляющиеся самым загадочным образом (в частности, привод TEAC, установленный в систему с драйвером CDR4_2K.SYS, доставшемся ему в наследство от PHILIPS'a, конфликтует с CD Player'ом, не соглашаясь отображать содержимое дисков с данными, если тот активен, после удаления же CDR4_2K.SYS все идет как по маслу).

Также не стоит забывать и о том, что корректирующая способность различных моделей приводов очень и очень неодинакова. Как пишет инженер-исследователь фирмы ЕПОС Павел Хлызов в своей статье "Проблема: неисправный CD-ROM": ": в зависимости от выбранной для конкретной модели CD-ROM стратегии коррекции ошибок и, соответственно, сложности процессора и устройства в целом, на практике тот или иной CD-ROM может либо исправлять одну-две мелкие ошибки в кадре информации (что соответствует дешевым моделям), либо в несколько этапов восстанавливать, с вероятностью 99,99%, серьезные и длинные разрушения информации. Как правило, такими корректорами ошибок оснащены дорогостоящие модели CD-ROM. Это и есть ответ на часто задаваемый вопрос: "Почему вот этот диск читается на машине товарища, а мой ПК его даже не видит? ".

Вообще-то, не совсем понятно, что конкретно господином инженером-исследователем имелось ввиду: корректирующие коды C 1 , C 2 , Q- и P- уровней корректно восстанавливают все известные мне приводы, и их корректирующая способность равна: до двух 2 ошибок на каждый из C 1 и C 2 уровней и до 86- и 52-ошибок на Q- и P- уровни соответственно. Правда, количество обнаруживаемых, но уже математически неисправимых ошибок составляет до 4 ошибок на C 1 и C 2 уровней и до 172/104 ошибок на Q/P, но: гарантированно определяется лишь позиция сбойных байт во фрейме/секторе, а не их значение. Впрочем, зная позицию сбойных байт и имея в своем распоряжении исходный HF-сигнал (т. е. аналоговый сигнал, снятый непосредственно со считывающей головки), кое-какие крохи информации можно и вытянуть, по крайней мере теоретически: так что приведенная выше цитата в принципе может быть и верна, однако, по наблюдениям автора данной статьи, цена привода очень слабо коррелирует с его "читабельной" способностью. Так, относительно дешевые ASUS читают практически все, а дорогие PHILIPS'ы даже свои родные диски с драйверами опознают через раз.

Другая немаловажная характеристика - доступный диапазон скоростей чтения. В общем случае - чем ниже скорость вращения диска, тем мягче требования, предъявляемые к его качеству. Правда, зависимость эта не всегда линейна. Большинство приводов имеют одну или несколько наиболее предпочтительных скоростей вращения, на которых их читабельная способность максимальна. Например, на скорости 8x дефектный диск читается на ура, а на всех остальных скоростях (скажем, 2x, 4x, 16x, 32x) - не читается вообще. Предпочтительная скорость легко определяется экспериментально, необходимо лишь перебрать полный диапазон доступных скоростей.

При покупке CD-ROM'a выбирайте тот привод, у которого скоростной диапазон максимален. Например, уже упомянутый выше PHILIPS CDRW 2400 умеет работать лишь на: 16x, 24x, 38x и 42x. Отсутствие скоростей порядка 4x - 8x ограничивает "рацион" привода только высококачественными дисками.

По непонятным причинам, штатные средства операционной системы Windows не позволяют управлять скоростью диска и потому приходится прибегать к помощи сторонних утилит, на недостаток которых, впрочем, жаловаться не приходится. Вы можете использовать Slow CD , Ahead Nero Drive Speed и т. д. Вообще-то, большинство приводов самостоятельно снижают скорость, натолкнувшись на не читающиеся сектора, однако качество заложенных в них алгоритмов все еще оставляет желать лучшего, поэтому "ручное" управление скоростью дает значительно лучший результат.

Если же ни на одном из доступных вам приводов диск все равно не читается, можно попробовать отшлифовать его какой-нибудь полировальной пастой. Технике полирования оптических поверхностей (и лазерных дисков в частности) посвящено огромное количество статей, опубликованных как в печатных изданиях, так и в Интернете (особенно полезны в этом смысле астрономические книги по телескопостроению), поэтому здесь этот вопрос будет рассмотрен лишь кратко. Да, действительно, поцарапанный диск в большинстве случав можно отполировать, и если все сделать правильно, диск с высокой степенью вероятности возвратится из небытия, но: Во-первых, полировка восстанавливает лишь царапины нижней поверхности диска и бессильна противостоять разрушениям отражающего слоя. Во-вторых, устраняя одни царапины, вы неизбежно вносите другие - после иной полировки лазерному диску может очень сильно поплохеть. В-третьих, полировке дисков невозможно научиться за раз, - вам понадобиться уйма времени и куча "подопытных" дисков. Нет уж, благодарю покорно! Лучше мы пойдем другим путем!

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

Диск не опознается приводом.

Вы вставляете диск в привод. Привод раскручивает диск, судорожно мигая при этом индикатором активности, затем, убедившись в том, что на заданной скорости диск не читается, начинает снижать обороты вплоть до полной остановки диска. Индикатор "DISK IN" (если он присутствует на лицевой панели привода) печально тухнет, давая тем самым понять, что кусок пластика, засунутый в привод, с точки зрения привода представляет собой все что угодно, но только не компакт-диск. При попытке обращения к диску выдается сообщение об отсутствии диска в дисководе и вежливое предложение его туда вставить.

Неспособность привода опознать диск в подавляющем большинстве случаев есть свидетельство неисправности CD-ROM привода. Реже - дефективности самого лазерного диска. Даже если вчера этот диск вполне уверенно опознавался, и даже если привод опознает все остальные диски - не спешите уверять себя в его, привода, работоспособности! Попробуйте прочитать диск на другом приводе. На худой конец - уменьшите скорость вращения диска до минимальной, однако будьте готовы к тому, что привод вас не послушается. Дело в том, что большинство приводов автоматически сбрасывают прежние установки скорости при смене диска и не позволяют изменять скорость вплоть до тех пор, пока диск не будет опознан (особенно этим "славятся" приводы TEAC, приводы от ASUS обычно ведут себя более демократично).

Если же подопытный диск отказывается опознаваться всеми доступными вам приводами, то причина скорее всего в том, что те не могут прочесть оглавление диска (также называемое TOC'ом ), хранящееся в Lead-In области. Выньте диск из привода и внимательно рассмотрите узкое блестящее кольцо, расположенное у внутреннего края диска - это и есть Lead-In. Нет ли на нем глубоких царапин или загрязнений? Загрязнения удалите чистой салфеткой (к слову сказать, при очистке диска про вводную область зачастую как-то забывают, вероятно принимая ее за бесполезное декоративное украшение). Бороться с царапинами намного труднее, и без надлежащего опыта полировки лазерных дисков за это дело лучше не браться. Лучше всего было бы отнести такой диск в сервисный центр, специализирующийся на восстановлении информации, однако далеко не во всяком городе такие центры вообще есть и далеко не всегда они выполняют такое восстановление оперативно и грамотно. Опять-таки: конфиденциальность, стоимость восстановления и прочее, прочее, прочее:

Можно ли восстановить такой диск самостоятельно? Да, можно, но для этого вам понадобится определенное оборудование, стоящее порядка 1000 рублей (~30$). Конкретно - отдельный CD-ROM привод, над которым будет не жалко поизмываться, и потерей которого вы окажетесь не слишком сильно огорчены (очень хорошо подходят для этих целей низкоскоростные приводы, оставшиеся от последнего апгрейда системы).

Весь фокус в том, что для работы с диском на сектором уровне TOC не так уж и нужен, и без него вполне можно обойтись. Фактически, это не аппаратная, а программная проблема. Обнаружив, что в процессе чтения оглавления диска возникли неустранимые ошибки, микропрограмма, зашитая в ПЗУ привода, отказывает такому диску в обработке, несмотря на то, что содержимое TOC'а дублировано в Q-канале подкода и размазано по всей спиральной дорожке. Причем привод реально нуждается лишь в трех основных полях TOC'a: адресе выводной области диска (чтобы знать: до сих пор можно дергать головкой), стартовом адресе первого трека (чтобы знать, откуда начинать чтение данных) и адресе следующей вводной области (только для многосессионных приводов). Со стартовым адресом первого трека разобраться проще всего - он по жизни равен 00:02:00 (что соответствует нулевому LBA-адресу). Адрес Lead-Out, напрямую зависящий от объема лазерного диска, не обязательно указывать точно, достаточно выбрать его таким, чтобы он был не меньше адреса настоящего Lead-Out, иначе все расположенные за ним сектора окажутся недоступными. Установив адрес Lead-Out на 80- или даже 90 минут мы можем гарантировать, что вся поверхность диска будет доступна приводу. Короче говоря, имей мы доступ ко внутренним структурам прошивки привода, восстановление разрушенного TOC'a было бы плевым делом. Автор использует для этих целей специальным образом модифицированную им прошивку обыкновенного CD-ROM привода (старенькая 8x модель от no name), которая позволяет манипулировать любыми служебными данными и потому читает все, что только физически можно прочесть.

Если же хачинье микропроцессорных программ вам не по зубам, можно пойти другим путем. Аккуратно разберите CD-ROM привод и извлеките его начинку из корпуса (теперь вы поняли, почему автор порекомендовал купить для этих целей отдельный - максимально дешевый - привод?). Теперь открутите болты, удерживающие металлическую планку, на которой закреплен эдакий "пятачок", прижимающийся к верхнему краю лазерного диска и тем самым уберегающий его от проскальзывания. Вместо этой некузявой конструкции вы можете использовать металлическое кольцо или иную тяжесть. Главное - получить свободный доступ к лазерному диску и возможность его "горячей" смены на ходу без выдвижения лотка.

Подключите CD-ROM к компьютеру и, включив питание последнего, нормальным путем вставьте в привод специальным образом подготовленный диск, адрес выводной области которого лежит в районе 80 - 90 минут (можно просто вставить любой CD с видеофильмом от 700 мегабайт). Убедившись, что диск нормально опознан, дождитесь его полной остановки и - не выключая компьютера - аккуратно снимите его с привода, ни в коем случае не открывая лоток. Теперь - установите в привод тот диск, который вы собираетесь восстанавливать. Поскольку TOC старого диска уже находится в кэше, а замену диска, совершенную таким варварским способом, привод обнаружить не в состоянии, он будет работать с новым диском точно так же, как и со старым. Только не пытайтесь читать содержимое диска средствами операционной системы - это ни к чему хорошему не приведет (ведь она тоже умеет кэшировать и сколько бы вы не жали на "обновить", в окне проводника будет неизменно прежнее оглавление). Лучше возьмите любой "грабер", читающий диск на секторном уровне и не задающий при этом лишних вопросов (можно воспользоваться утилитой cd_ raw_ read , бесплатно распространяемой автором этой статьи) и скопируйте все содержимое диска от первого сектора до последнего в файл-образ, а затем, используя любую подходящую программу "прожига", залейте его на CD-R или CD-RW. Пусть вы не восстановите сам диск, но зато - его содержимое! Эта методика с одинаковым успехом применима как для аудиодисков, так и для дисков с данными.

Как вариант: можно не откручивать прижимную планку, а найти датчик смены диска и на время сделать ему "харакири", заставляя привод думать, что восстанавливаемый диск не был заменен (дешевые приводы используют простые механические датчики, сразу же бросающиеся в глаза, в более дорогих моделях отдельного датчика вообще нет и признаком смены диска считается нажатие на EJECT; в этом случае с некоторым риском можно воспользоваться отверстием для аварийного извлечения диска, однако имейте ввиду, что извлечение диска на работающем приводе может необратимо искалечить его механическую часть).

К слову сказать, существуют и такие приводы, которые ухитряются читать диск даже при полностью разрушенном TOC'е. К ним, в частности, относятся некоторые модели "писцов" от MSI. Обладателям этих приводов незачем развинчивать свой CD-ROM - сбойный диск он прочтет и так.

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

Диск опознается приводом, но не опознается операционной системой.

Вы вставляете диск в привод. Привод раскручивает диск, зажигает индикатор DISK IN (если он есть), однако попытка просмотра содержимого диска штатными средствами операционной системы приводит к сообщению о той или иной ошибке. Сканирование поверхности диска утилитой Ahead Nero CD Speed (или любой другой утилитой аналогичного назначения) выявляет один или несколько разрушенных (damaged) секторов.

Это явный симптом повреждения файловой системы, а точнее - ее корневого каталога. Если это произошло - не хватайтесь за сердце. Восстановление коревого каталога лазерных дисков, в отличие от винчестеров и дискет, не представляет большой проблемы. Подавляющее большинство лазерных дисков содержат не одну, а сразу две файловых системы, дублирующих друг друга - ISO 9660 и Joliet (таковыми являются все диски, выпущенные после 1995 года). Согласитесь, одновременное разрушение сразу двух корневых каталогов - событие крайне маловероятное. К тому же, в силу отсутствия фрагментации, вложенные подкаталоги не разбросаны по всей поверхности лазерного диска, а сосредоточены в одном месте, благодаря чему даже при полностью разрушенном корневом каталоге их достаточно легко восстановить. Наконец, каждая последующая сессия многосессионого диска включает в себя содержимое файловых систем всех предыдущих сессий (исключая, разумеется, удаленные файлы). А потому, при смерти файловой системы последней сессии мы без труда можем спасти содержимое всех остальных.

К сожалению, штатные средства Windows не предоставляют возможности выборочного монтирования ни предпочтительной файловой системы, ни предпочтительной сессии, принудительно подсаживая нас на корневой каталог Джульеты последней сессии диска. Самое простое, что можно сделать - попробовать прочитать диск под голой MS-DOS с установленным драйвером MSCDEX, работающим исключительно с ISO 9660 и игнорирующим существование Joliet. Как вариант, вы можете воспользоваться утилитой ISO 9660.dir , разработанной автором специально для работы с порушенными файловыми системами и восстанавливающей все, что только можно восстановить.

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

При вставке диска в привод компьютер зависает.

Вы вставляете диск в привод, привод раскручивает диск, интенсивно мигая индикатором активности, и: зависает, зачастую завешивая вместе с собой и операционную систему. В легких случаях положение спасает EJECT, в тяжелых - RESET.

Такое поведение характерно для защищенных дисков, защита которых основана на искаженном TOC'e. Большинство приводов к искаженному TOC'у относятся довольно лояльно (хотя это смотря еще что искажать), но встречаются и такие, которые при этом просто виснут. Если прочесть защищенный диск все же необходимо - попробуйте сменить привод.

Другой возможный вариант - зацикленная файловая система. При "прожиге" CD-R/CD-RW дисков кривым софтом такое часто случается. Удерживая SHIFT во время загрузки диска, запретите операционной системе читать его содержимое (или же просто временно отключите автозапуск) и посредством той же утилиты ISO 9660.dir вытяните из диска все, что только с него можно вытянуть.

Диск читается с ошибками.

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

Прежде всего: ошибка ошибке рознь. Редко бывает так, чтобы сектор не читался весь целиком. Как правило, речь идет об искажении одного или нескольких принадлежащих ему байт. Причем корректирующая способность избыточных кодов такова, что до 392 сбойных байт исправляется уже в декодере первого уровня (CIRC-декодере). Еще до 86 ошибок способны исправлять P-коды и до 52 ошибок - Q-коды. Т. е. при наиболее благоприятном распределении ошибок удается восстановить вплоть до 530 ошибок или до ~25% общей емкости сектора. Лишь чудовищная ненадежность оптических носителей приводит к тому, что даже такая колоссальная избыточность данных иной раз не в силах противостоять сбоям.

В зависимости от установочных параметров, накопитель, обнаружив неустранимый сбой, либо отдает сектор в том виде, в котором его удалось прочесть, либо же просто рапортует об ошибке, оставляя содержимое выходного буфера в неопределенном состоянии. Идея восстановления состоит в том, чтобы заставить привод выдавать все, что он только способен прочесть. Конечно, искаженные байты уже не вернуть назад, однако многие форматы файлов вполне лояльно относятся к небольшим разрушениям. Музыка в формате mp3/wma, видеофильмы, графические изображения - все они будут вполне нормально воспроизводиться: только непосредственно на месте самого искажения возникнет щелчок той или иной громкости или мелькнет "артефакт". С архивами ситуация обстоит значительно хуже, но в подавляющем большинстве случаев вы потеряете всего один-единственный файл, а все остальное содержимое архива распакуется нормально (кстати, некоторые архиваторы, такие например, как RAR поддерживают собственные корректирующие коды, позволяющие при минимальной избыточности восстанавливать "битые" архивы).

"Постойте! - возразят мне иные читатели. - Как же было дело! Пробовали мы восстанавливать не читающиеся диски теми или иными утилитами. Ну и что? "Вылеченный" mpg или avi система наотрез отказалась считать видео-файлом! " "Так все дело в том, - резонно возражу я, - что эти самые утилиты просто выкидывали все сектора, которые они не могли прочесть, в результате чего размер файла, а значит, и относительные смещения всех его структур изменились! Неудивительно, что после такой кастрации он перестал воспроизводиться!"

Воспользуйтесь любым копировщиком защищенных дисков, предоставляющим выборочное управление режимом обработки ошибок и выберите режим 24h (максимально возможная коррекция ошибок без прерывания передачи данных в случае невозможности их восстановления). Среди прочих утилит для этой цели подойдет тот же cd_raw_read, разработанный автором. Как альтернативный вариант вы можете использовать Alcohol 120% и/или Clone CD.

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

Немногочисленные узкие царапины, в общем-то, не опасны - содержимое сектора размазано вдоль спиральной дорожки и потому выпадения нескольких байт легко компенсируются за счет избыточности. Правда, тут есть одно "но". Откуда приводу знать сколько именно "питов" и "лендов" было пропущено? Поскольку "питы" и "ленды" напрямую не соответствуют двоичному нулю и единице, и единица кодируется переходом от "пита" к "ленду" или наоборот, а нуль - отсутствуем переходов на данном участке, становится понятно, что пропадание нечетного числа "питов"/"лентов" как бы переворачивает весь хвост фрейма с ног на голову, т. е., другими словами, - его гробит. Отсюда: даже одна-единственная царапина способна породить целый каскад ошибок, неустранимых штатными корректирующими кодами, но, в принципе, поддающихся ремонту вручную. Ну, не то, чтобы совсем вручную, - необходимая для этой цели утилита уже написана автором и сейчас проходит стадию альфа-тестирования, на ура читая те диски, которые не читались нормальным путем. Не исключено, что к моменту выхода данной статьи она перейдет в стадию бета-тестирования и станет бесплатно доступна всем желающим. Впрочем, поскольку длина одного фрейма составляет всего 24 байта, разрушение нескольких подряд идущих фреймов может быть реконструировано и штатными корректирующими кодами, и к помощи моей утилиты приходится прибегать лишь на сильно поцарапанных дисках.

Широкие царапины - другое дело. Мало того, что они "съедают" несколько фреймов целиком, так еще и сбивают оптическую головку с дорожки. Попав в образованную царапиной дыру, головка совершенно дезориентируются (ей становится попросту не на что опираться!) и "вылетает" в одну из соседних дорожек. Умные приводы автоматически распознают такую ситуацию и позиционируют головку на нужное место. Приводы поглупее (коих, кстати, подавляющее большинство) самоуверенно продолжают чтение, как ни в чем не бывало. В результате, голова одного сектора скрещивается с хвостом другого и: естественно, при попытке восстановления такого сектора штатными корректирующими кодами ничего, кроме мусора, не получается, и привод уныло диагностирует неисправимую ошибку. Выход - читать такой сектор до тех пор, пока головка не попадет на ту же самую дорожку, с которой начиналось чтение сектора. Количество попыток чтения при этом должно быть достаточно велико (от 100 и больше). Ведь с точки зрения вероятности отклониться от спиральной дорожки намного проще, чем удержаться на ней!

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

Царапины, расположенные с нижней стороны диска, в большинстве случав устраняются полировкой, а вот царапины, "высверлившие" рабочий слой, ликвидировать - увы! - невозможно.

Отредактировано Viking (2007-01-26 13:36:06)

0

2

Угу, видел эту статейку уже.

0

3

может там написано  то что я  напишу ниже)))тупо лень было читать)))

в некоторых случая диск можно реанимировать если покрыть его  оптическую поверхность ЗЕЛЕНКОЙ...говорят что по строению кристаллов Зеленка похожа на спец. пасту которая восстанавливает диЗЗГИ

САМ НЕ ПРОБОВАЛ НО ГОВОРЯТ ЧТО РАБОТАЕТ....

0

4

Вот хорошая статья по востановлению данных=)источник журнал спец Хакер=)
предупреждаю сразу что чайники не поймут,хотя хз

ВОССТАНОВЛЕНИЕ УДАЛЕННЫХ ФАЙЛОВ

КТО НЕ УДАЛЯЛ ФАЙЛОВ И ПОТОМ ГОТОВ БЫЛ ПОВЕСИТЬСЯ, ЧТОБЫ ВЕРНУТЬ ИХ ОБРАТНО? ОСОБЕННО ЛЕГКО УДАЛЯТЬ ДАННЫЕ С ПОМОЩЬЮ КОМАНДНОЙ СТРОКИ, КОГДА ЛИШНИЙ ПРОБЕЛ ИЛИ СИМВОЛ ЗВЕЗДОЧКИ ТРУТ ВСЕ ПОДЧИСТУЮ. ХОЧЕШЬ УЗНАТЬ, КАК ЭТОМУ ПРОТИВОСТОЯТЬ?

xBSD поддерживает множество файловых систем: FAT16/32, ext2fs/ext3fs, ISO 9660, UDF, NFS, SMBFS, NTFS, ReiserFS, XF, AFS, LFS, но основной системой, устанавливаемой по умолчанию, была и остается UFS/UFS2.

Многие коммерческие UNIX'ы также используют либо саму UFS, либо нечто очень на нее похожее. В противоположность ext2fs, исхоженной вдоль и поперек, UFS (равно как и ее наследница FFS) практически недокументированна и в доступной литературе описана поверхностно. Единственным источником информации становятся исходные тексты, в которых не так-то просто разобраться!

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

[немного истории.]

UFS расшифровывается как UNIX File System и ведет свою историю от S5 FS — самой первой файловой системы, написанной для UNIX в далеком 1974 году. S5 FS была крайне простой и неповоротливой (по некоторым данным - 2%-5% от «сырой» производительности голого диска), но понятия суперблока (super-block), файловых записей (inodes) и блоков данных (blocks) в ней уже существовали.

В процессе работы над дистрибутивом 4.2 BSD, вышедшим в 1983 году, ординальная файловая система претерпела некоторые улучшения. Были добавлены длинные имена, символические ссылки и т. д. Так родилась UFS.

В 4.3 BSD, увидевшей свет уже в следующем году, улучшения носили намного более радикальный, если не сказать революционный, характер. Появились концепции фрагментов (fragments) и групп цилиндров (cylinder groups). Быстродействие файловой системы существенно возросло, что и определило ее название FFS – Fast File System (быстрая файловая система).

Все последующие версии линейки 4.x BSD прошли под знаменем FFS, но в 5.x BSD файловая система вновь изменилась. Для поддержки дисков большого объема ширину всех адресных полей пришлось удвоить: 32-битная нумерация фрагментов уступила место 64-битной. Были внесены и другие менее существенные усовершенствования.

Фактически, мы имеем дело с тремя различными файловыми системами, не совместимыми друг с другом на уровне базовых структур данных. Однако некоторые источники склонны рассматривать FFS как надстройку над UFS. Из Little UFS2 FAQ следует, что «UFS/UFS2 определяет раскладку данных на диске. FFS реализована поверх UFS 1 или 2 и отвечает за структуру директорий и некоторых дисковых оптимизаций». Действительно, если заглянуть в исходные тексты файловой системы, можно обнаружить два подкаталога — /ufs и /ffs. В /ffs находится определение суперблока (базовой структуры, отвечающей за раскладку данных), а в /ufs – определение inode и структуры директорий, что опровергает данный тезис, с точки зрения которого все должно быть с точностью до наоборот.

Чтобы не увязнуть в болоте терминологических тонкостей, под UFS мы будем понимать основную файловую систему 4.5 BSD, а под UFS2 – основную файловую систему 5.х BSD.

[структура UFS.]

В начале диска расположен boot-сектор (на незагрузочных разделах он может быть пустым), а все остальное пространство поделено на несколько зон одинакового размера, называемых группами цилиндров (cylinder groups). Каждая группа цилиндров имеет свой суперблок (super-block), свою таблицу inode (Index-node) и свою группу блоков данных, совершенно независимую от всех остальных зон. Другим словами, inode описывает блоки данных той и только той зоны, к которой она принадлежит. Это увеличивает быстродействие файловой системы (головка жесткого диска совершает более короткие перемещения) и упрощает процедуру восстановления при значительном разрушении данных, поскольку, как показывает практика, обычно гибнет только первая группа inode. Чтобы погибли все группы... что же такого с жестким диском нужно сделать?! Под пресс положить, наверно.

Каждый блок, в свою очередь, разбит на несколько фрагментов фиксированного размера, предотвращающих потерю свободного пространства в хвостах файлов. Благодаря этому, использование блоков большого размера уже не кажется расточительной идей: напротив, это увеличивает производительность и уменьшает фрагментацию. Если файл использует более одного фрагмента в двух несмежных блоках, он автоматически перемещается на новое место, в наименее фрагментированный регион свободного пространства. Поэтому фрагментация в UFS очень мала или же совсем отсутствует, что существенно облегчает восстановление удаленных файлов и разрушенных данных.

Адресация ведется либо по физическим смещениям, измеряемым в байтах и отсчитываемым от начала группы цилиндров (реже — от UFS-раздела), либо по номерам фрагментов, отсчитываемым от тех же самых точек. Допустим, размер блока составляет 16 Кбайт, разбитых на 8 фрагментов. Тогда сектор 69 будет иметь смещение 512 х 69 = 35328 байт или 1024 x (16/8)/512 x 69 = 276 фрагментов.

В USF первый cуперблок располагается по смещению 8192 байт от конца загрузочного сектора, что соответствует 17-му сектору. В UFS2 он «переехал» на 65536 байт (129 секторов) от начала, освобождая место для дисковой метки и первичного загрузчика операционной системы. А для действительно больших (в исходных текстах — piggy, то есть «свинских») систем предусмотрена возможность перемещения суперблока по адресу 262144 байт (целых 513 секторов).

Вслед за суперблоком идут одна или несколько групп цилиндров, описываемых дескрипторами групп (group descriptors), карты свободного пространства (в просторечии — битмапы, block bitmap/inode bitmap) и таблицы inode. Для перестраховки копия суперблока дублируется в каждой группе. Загрузочный сектор не дублируется, но по соображениям унификации под него просто выделяется место. Таким образом, относительная адресация блоков в каждой группе остается неизменной.

Среди прочей информации суперблок содержит:

- cblkno — смещение первой группы блока цилиндров, измеряемый в фрагментах, отсчитываемых от начала раздела;

- fs_iblkno — смещение первой inode в первой группе цилиндров (фрагменты от начала раздела);

- fs_dblkno — смещение первого блока данных в первой группе цилиндров (фрагменты от начала раздела);

- fs_ncg — количество групп цилиндров (штуки);

- fs_bsize – размер одного блока в байтах;

- fs_fsize — размер одного фрагмента в байтах;

- fs_frag — количество фрагментов в блоке;

- fs_fpg – размер каждой группы цилиндров, выраженный в блоках (может быть найден через fs_cgsize);

Для перевода смещений, выраженных в фрагментах, в номера секторов служит следующая формула: sec_n(fragment_offset) = fragment_offset * (fs_bsize / fs_frag / 512). Или ее более короткая разновидность: sec_n(fragment_offset) = fragment_offset * fs_fsize / 512.

Формат суперблока (определен в файле /src/ufs/ffs/fs.h, второстепенные поля опущены)

struct fs {

/* 0x00 */ int32_t fs_firstfield; /* historic file system linked list, */

/* 0x04 */ int32_t fs_unused_1; /* used for incore super blocks */

/* 0x08 */ ufs_daddr_t fs_sblkno; /* addr of super-block in filesys */

/* 0x0C */ ufs_daddr_t fs_cblkno; /* offset of cyl-block in filesys */

/* 0x10 */ ufs_daddr_t fs_iblkno; /* offset of inode-blocks in filesys */

/* 0x14 */ ufs_daddr_t fs_dblkno; /* offset of first data after cg */

/* 0x18 */ int32_t fs_cgoffset; /* cylinder group offset in cylinder */

/* 0x1C */ int32_t fs_cgmask; /* used to calc mod fs_ntrak */

/* 0x20 */ time_t fs_time; /* last time written */

/* 0x24 */ int32_t fs_size; /* number of blocks in fs */

/* 0x28 */ int32_t fs_dsize; /* number of data blocks in fs */

/* 0x2C */ int32_t fs_ncg; /* number of cylinder groups */

/* 0x30 */ int32_t fs_bsize; /* size of basic blocks in fs */

/* 0x34 */ int32_t fs_fsize; /* size of frag blocks in fs */

/* 0x38 */ int32_t fs_frag; /* number of frags in a block in fs */

/* these are configuration parameters */

/* 0x3С */ int32_t fs_minfree; /* minimum percentage of free blocks */

/* 0x40 */ int32_t fs_rotdelay; /* num of ms for optimal next block */

/* 0x44 */ int32_t fs_rps; /* disk revolutions per second */

/* sizes determined by number of cylinder groups and their sizes */

/* 0x98 */ ufs_daddr_t fs_csaddr; /* blk addr of cyl grp summary area */

/* 0x9C */ int32_t fs_cssize; /* size of cyl grp summary area */

/* 0xA0 */ int32_t fs_cgsize; /* cylinder group size */

/* these fields can be computed from the others */

/* 0xB4 */ int32_t fs_cpg; /* cylinders per group */

/* 0xB8 */ int32_t fs_ipg; /* inodes per group */

/* 0xBC */ int32_t fs_fpg; /* blocks per group * fs_frag */

/* these fields are cleared at mount time */

/* 0xD0 */ int8_t fs_fmod; /* super block modified flag */

/* 0xD1 */ int8_t fs_clean; /* file system is clean flag */

/* 0xD2 */ int8_t fs_ronly; /* mounted read-only flag */

/* 0xD3 */ int8_t fs_flags; /* see FS_ flags below */

/* 0xD4 */ u_char fs_fsmnt[MAXMNTLEN]; /* name mounted on */

};

В некотором отдалении от конца суперблока находится первая группа цилиндров. В начале каждой группы расположена служебная структура cg — описатель группы цилиндров, содержащая магическую последовательность 55h 02h 09h, по которой все уцелевшие группы можно найти даже при полностью испорченном суперблоке (стартовые адреса всех последующих групп вычисляются путем умножения номера группы на ее размер, содержащийся в поле fs_cgsize).

Другие важные параметры:

- cg_cgx — порядковой номер группы, отсчитываемый от ноля;

- cg_old_niblk — количество inode в данной группе;

- cg_ndblk — количество блоков данных в рассматриваемой группе;

- csum — количество свободных inode и блоков данных в рассматриваемой группе;

- cg_iusedoff — смещение карты занятых inode, отсчитываемое от начала данной группы и измеряемое в байтах;

- cg_freeoff — смещение карты свободного пространства (байты от начала группы).

Структура описателя группы цилиндров (определена в файле /src/ufs/ffs/fs.h)

#define CG_MAGIC 0x090255

#define MAXFRAG 8

struct cg {

/* 0x00 */ int32_t cg_firstfield; /* historic cyl groups linked list */

/* 0x04 */ int32_t cg_magic; /* magic number */

/* 0x08 */ int32_t cg_old_time; /* time last written */

/* 0x0С */ int32_t cg_cgx; /* we are the cgx'th cylinder group */

/* 0x10 */ int16_t cg_old_ncyl; /* number of cyl's this cg */

/* 0x12 */ int16_t cg_old_niblk; /* number of inode blocks this cg */

/* 0x14 */ int32_t cg_ndblk; /* number of data blocks this cg */

/* 0x18 */ struct csum cg_cs; /* cylinder summary information */

/* 0x28 */ int32_t cg_rotor; /* position of last used block */

/* 0x2С */ int32_t cg_frotor; /* position of last used frag */

/* 0x30 */ int32_t cg_irotor; /* position of last used inode */

/* 0x34 */ int32_t cg_frsum[MAXFRAG]; /* counts of available frags */

/* 0x54 */ int32_t cg_old_btotoff; /* (int32) block totals per cylinder */

/* 0x58 */ int32_t cg_old_boff; /* (u_int16) free block positions */

/* 0x5С */ int32_t cg_iusedoff; /* (u_int8) used inode map */

/* 0x60 */ int32_t cg_freeoff; /* (u_int8) free block map */

/* 0x64 */ int32_t cg_nextfreeoff; /* (u_int8) next available space */

/* 0x68 */ int32_t cg_clustersumoff; /* (u_int32) counts of avail clusters */

/* 0x6С */ int32_t cg_clusteroff; /* (u_int8) free cluster map */

/* 0x70 */ int32_t cg_nclusterblks; /* number of clusters this cg */

/* 0x74 */ int32_t cg_niblk; /* number of inode blocks this cg */

/* 0x78 */ int32_t cg_initediblk; /* last initialized inode */

/* 0x7С */ int32_t cg_sparecon32[3]; /* reserved for future use */

/* 0x00 */ ufs_time_t cg_time; /* time last written */

/* 0x00 */ int64_t cg_sparecon64[3]; /* reserved for future use */

/* 0x00 */ u_int8_t cg_space[1]; /* space for cylinder group maps */

/* actually longer */

Между описателем группы цилиндров и группой inode расположена карта занятых inode и карта свободного дискового пространства, которые представляют собой обыкновенные битовые поля, точно такие же, как и в NTFS. При восстановлении удаленных файлов без этих карт никуда! Они существенно сужают круг поиска, что особенно хорошо заметно на дисках, заполненных более чем наполовину.

За картами следует массив inode, смещение которого содержится в поле cg_iusedoff (адрес первой группы inode продублирован в суперблоке). В UFS inode играет ту же самую роль, что и FILE Record в NTFS (в FAT прямых аналогов нет). Здесь сосредоточена вся информация о файле: тип файла (обычный файл, директория, символьная ссылка и т. д.), логический и физический размер, схема размещения на диске, время создания, модификации, последнего доступа и удаления, права доступа и количество ссылок на файл.

По сути, в UFS структура inode ничем не отличается от ext2fs, только расположение полей другое. К тому же имеется только один блок косвенной адресации вместо трех, но это уже детали, в которые не будем углубляться (иначе или зависнем, или завязнем). Лучше рассмотрим назначение фундаментальных полей, к числу которых принадлежат:

- di_nlink — количество ссылок на файл (0 означает «удален»);

- di_size — размер файла в байтах;

- di_atime/di_atimensec — время последнего доступа к файлу;

- di_mtime/di_mtimensec — время последней модификации;

- di_ctime/di_ctimensec – время последнего изменения inode;

- di_db – адреса первых 12-ти блоков данных файла, отсчитываемые в фрагментах от начала группы цилиндров;

- di_ib — адреса блоков косвенной адресации (фрагменты от начала группы).

Структура inode в USF1 (определена в файле /src/ufs/ufs/dinode.h)

struct dinode {

/* 0x00 */ u_int16_t di_mode; /* 0: IFMT, permissions; see below. */

/* 0x02 */ int16_t di_nlink; /* 2: File link count. */

/* 0x04 */ union {

u_int16_t oldids[2]; /* 4: Ffs: old user and group ids. */

int32_t inumber; /* 4: Lfs: inode number. */

} di_u;

/* 0x08 */ u_int64_t di_size; /* 8: File byte count. */

/* 0x10 */ int32_t di_atime; /* 16: Last access time. */

/* 0x14 */ int32_t di_atimensec; /* 20: Last access time. */

/* 0x18 */ int32_t di_mtime; /* 24: Last modified time. */

/* 0x1C */ int32_t di_mtimensec; /* 28: Last modified time. */

/* 0x20 */ int32_t di_ctime; /* 32: Last inode change time. */

/* 0x24 */ int32_t di_ctimensec; /* 36: Last inode change time. */

/* 0x28 */ ufs_daddr_t di_db[NDADDR]; /* 40: Direct disk blocks. */

/* 0x58 */ ufs_daddr_t di_ib[NIADDR]; /* 88: Indirect disk blocks. */

/* 0x64 */ u_int32_t di_flags; /* 100: Status flags (chflags). */

/* 0x68 */ int32_t di_blocks; /* 104: Blocks actually held. */

/* 0x6C */ int32_t di_gen; /* 108: Generation number. */

/* 0x70 */ u_int32_t di_uid; /* 112: File owner. */

/* 0x74 */ u_int32_t di_gid; /* 116: File group. */

/* 0x78 */ int32_t di_spare[2]; /* 120: Reserved; currently unused */

};

В UFS2 формат inode был существенно изменен — появилось множество новых полей, удвоилась ширина адресных полей и т. д. Что это обозначает в практическом плане? Смещения всех полей изменились, только и всего, а общий принцип работы остался прежним.

Структура inode в USF2

struct ufs2_dinode {

/* 0x00 */ u_int16_t di_mode; /* 0: IFMT, permissions; see below. */

/* 0x02 */ int16_t di_nlink; /* 2: File link count. */

/* 0x04 */ u_int32_t di_uid; /* 4: File owner. */

/* 0x08 */ u_int32_t di_gid; /* 8: File group. */

/* 0x0C */ u_int32_t di_blksize; /* 12: Inode blocksize. */

/* 0x10 */ u_int64_t di_size; /* 16: File byte count. */

/* 0x18 */ u_int64_t di_blocks; /* 24: Bytes actually held. */

/* 0x20 */ ufs_time_t di_atime; /* 32: Last access time. */

/* 0x28 */ ufs_time_t di_mtime; /* 40: Last modified time. */

/* 0x30 */ ufs_time_t di_ctime; /* 48: Last inode change time. */

/* 0x38 */ ufs_time_t di_birthtime; /* 56: Inode creation time. */

/* 0x40 */ int32_t di_mtimensec; /* 64: Last modified time. */

/* 0x44 */ int32_t di_atimensec; /* 68: Last access time. */

/* 0x48 */ int32_t di_ctimensec; /* 72: Last inode change time. */

/* 0x4C */ int32_t di_birthnsec; /* 76: Inode creation time. */

/* 0x50 */ int32_t di_gen; /* 80: Generation number. */

/* 0x54 */ u_int32_t di_kernflags; /* 84: Kernel flags. */

/* 0x58 */ u_int32_t di_flags; /* 88: Status flags (chflags). */

/* 0x5C */ int32_t di_extsize; /* 92: External attributes block. */

/* 0x60 */ ufs2_daddr_tdi_extb[NXADDR];/* 96: External attributes block. */

/* 0x70 */ ufs2_daddr_tdi_db[NDADDR]; /* 112: Direct disk blocks. */

/* 0xD0 */ ufs2_daddr_tdi_ib[NIADDR]; /* 208: Indirect disk blocks. */

/* 0xE8 */ int64_t di_spare[3]; /* 232: Reserved; currently unused */

};

Имена файлов хранятся в директориях. В inode их нет. С точки зрения UFS, директории являются обыкновенными файлами (ну, не совсем обыкновенными) и могут храниться в любом месте, принадлежащем группе цилиндров. Файловая система UFS поддерживает несколько типов хеширования директорий, однако на структуре хранения имен это никак не отражается. Имена хранятся в блоках, называемых DIRBLKSIZ в структурах типа direct, выровненных по 4-байтовой границе.

Структура direct определена в файле /src/ufs/ufs/dir.h и содержит: номер inode, описывающий данный файл, тип файла, его имя, а так же длину самой структуры direct, используемую для нахождения следующего direct'а в блоке.

Структура direct, отвечающая за хранение имен файлов и директорий

struct direct {

/* 0x00 */ u_int32_t d_ino; /* inode number of entry */

/* 0x04 */ u_int16_t d_reclen; /* length of this record */

/* 0x06 */ u_int8_t d_type; /* file type, see below */

/* 0x07 */ u_int8_t d_namlen; /* length of string in d_name */

/* 0x08 */ char d_name[MAXNAMLEN + 1];/* name with length <= MAXNAMLEN */

};

[что происходит при удалении файла.]

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

1 В суперблоке обновляется поле fs_time (время последнего доступа к разделу).

2 В суперблоке обновляется структура fs_cstotal (количество свободных inode и блоков данных в разделе).

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

4 В inode материнского каталога обновляются поля времени последнего доступа и модификации.

5 В inode материнского каталога обновляется поле времени последнего изменения inode.

6 В inode удаляемого файла поля di_mode (IFMT, permissions), di_nlink (количество ссылок на файл) и di_size (размер файла) варварски обнуляются.

7 В inode удаляемого файла поля di_db (массив указателей на 12 первых блоков файла) и di_ib (указатель на блок косвенной адресации) безжалостно затираются нулями.

8 В inode удаляемого файла обновляются поля времени последней модификации и изменения inodе. Время последнего доступа при этом остается неизменным.

9 В inode удаляемого файла обновляется поле di_spare. В исходных текстах оно помечено как «Reserved; currently unused», но просмотр дампа показывает, что это не так. Судя по всему, здесь хранится нечто вроде последовательности обновления (update sequence), используемой для контроля целостности inode. Но это только предположение.

10 В директории удаленного файла размер предшествующей структуры direct увеличивается на d_reclen. В результате чего она как бы «поглощает» имя удаляемого файла, но его затирания не происходит. Во всяком случае, оно затирается не сразу, а только тогда, когда в этом возникнет реальная необходимость.

[подготовка к восстановлению.]

Если ты только что удалил файл, то лучшим способом восстановления будет RESET. Без шуток! Система сбрасывает дисковые буферы не сразу, а спустя некоторое время, поэтому своевременная перезагрузка или отключение питания спасут ситуацию, и после загрузки файл окажется целым и невредимым, правда, на самом диске могут образоваться значительные разрушения, так что риск неблагоприятного исхода очень велик, и лучше воспользоваться более традиционными средствами восстановления :).

Первым делом размонтируй (unmount) дисковый раздел или перемонтируй его «только на чтение». Лечение активных разделов обычно заканчивается очень печально. Если восстанавливаемые файлы находятся в системном разделе, можно прибегнуть к LiveCD. Лучше всего использовать KNOPPIX. Он поддерживает большое количество оборудования, не требователен к ресурсам (достаточно всего 128 Мбайт памяти) и содержит все необходимые утилиты для восстановления. Опытные пользователи могут сформировать загрузочный CD или даже дискету самостоятельно.

Широко разрекламированный дистрибутив Ferenzy 0.3, основанный на Free BSD, лучше сразу выкинуть в помойку — совсем немного дисковых утилит, да и те ориентированны в основном на ext2fs, а USF/FFS поддерживает постольку поскольку. Тем не менее, для восстановительных работ данный диск вполне пригоден, если ничего другого под рукой нет...

Дисковых редакторов, работающих на уровне секторов, под BSD существует не так уж и много. Обычно для этой цели пользуются BSD-портом LINUX-редактора lde (http://lde.sourceforge.net). Но, к сожалению, когда мы тестировали его на системе 4.5 BSD, он работал крайне нестабильно и не отображал основные структуры данных в удобочитаемом виде, хотя поддержка UFS в нем заявлена. В принципе, можно вставить в привод загрузочный CD-ROM с Windows PE и воспользоваться любым Windows-редактором от Microsoft Disk Probe до Runtime Disk Explorer'а. То же самое справедливо и для Norton Disk Editor'а, запущенного c дискеты из-под MS-DOS (правда, ни диски большого объема, ни SCSI-устройства он не поддерживает). Еще можно запустить KNOPPIX или любой Live LINUX, ориентированный на восстановление, но дело в том, что, редактируя диск напрямую, его легко испортить. Одно неверное движение руки — и гигабайты данных обращаются в прах.

При наличии свободного места рекомендуется создать копию раздела и все дальнейшие опыты проводить уже над ней. В мире Windows для этой цели требуются специальные утилиты (например Norton Ghost), которые, кстати говоря, стоят нехилых денег. Но BDS – совсем другое дело. Здесь все необходимое находится под рукой. Копию раздела проще всего создать командой cp /dev/ad0s1a dump, где ad0s1a – имя устройства, а dump — имя файла-дампа, для работы с которым сгодится любой hex-редактор (например, biew - http://biew.sourceforge.net).

[техника ручного восстановления файлов.]

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

Если нам повезет, и файл окажется нефрагментированным (а на UFS, как уже отмечалось, фрагментация обычно отсутствует или крайне невелика), остальное будет делом техники. Просто выделяешь группу секторов и записываешь ее на диск, но только ни в коем случае не на сам восстанавливаемый раздел! К примеру, файл можно передать на соседнюю машину по сети. К сожалению, поле длины файла безжалостно затирается при его удалении, и актуальный размер приходится определять «на глазок». Звучит намного страшнее, чем выглядит. Неиспользуемый хвост последнего фрагмента всегда забивается нулями, что дает хороший ориентир. Проблема в том, что некоторые типы файлов содержат в своем конце некоторое количество нулей, при отсечении которых их работоспособность нарушается, поэтому тут приходится экспериментировать.

А если файл фрагментирован? Первые 13 блоков (именно блоков, а не фрагментов!) придется собирать руками. В идеале это будет один непрерывный регион. Хуже, если первый фрагмент расположен в «чужом» блоке (то есть блоке, частично занятом другим файлом), а оставшиеся 12 блоков находятся в одном или нескольких регионах. Вообще-то, достаточно трудно представить себе ситуацию, в которой первые 13 блоков были бы сильно фрагментированы (а поддержка фоновой дефрагментации в UFS на что?!). Такое может произойти только при интересной «перегруппировке» большого количеств файлов, что в реальной жизни практически никогда не встречается, разве только если ты задумал навести порядок на своем жестком диске :). Короче, будем считать, что 13-ый блок файла найден. В массив непосредственной адресации он уже не влезает (там содержатся только 12 блоков), и ссылка на него, как и на все последующие блоки файла, должна содержаться в блоках косвенной адресации, которые при удалении файла помечаются как свободные, но не затираются. Точнее затираются, но не сразу. Большинство файлов обходятся только одним косвенным блоком, что существенно упрощает нашу задачу.

Как найти этот блок на диске? Вычисляем смещение 13-го блока файла от начала группы цилиндров, переводим его в фрагменты, записываем получившееся число задом наперед (так, чтобы младшие байты располагались по меньшим адресам) и осуществляем контекстный поиск в свободном пространстве. Отличить блок косвенной адресации от всех остальных типов данных очень легко — он представляет собой массив указателей на блоки, а в конце идут нули. Остается только извлечь эти блоки с диска и записать их в файл, обрезая его по нужной длине. Внимание! Если ты нашел несколько «кандидатов» в блоки косвенной адресации, это означает, что 13-ый блок удаленного файла в разное время принадлежал различным файлам (а так, скорее всего, и будет). Не все косвенные блоки были затерты - вот ссылки и остались.

Как отличить «наш» блок от «чужих»? Если хотя бы одна из ссылок указывает на уже занятый блок данных (что легко определить по карте), такой блок можно сразу откинуть. Оставшиеся блоки перебираются вручную до получения работоспособной копии файла. Имя файла, если оно еще не затерто, можно извлечь из директории. Естественно, при восстановлении нескольких файлов ты не можешь однозначно сказать, какое из имен какому файлу принадлежит. Тем не менее, это все же лучше, чем совсем ничего. Директории восстанавливаются точно так же, как и обыкновенные файлы, хотя, по правде говоря, в них кроме имен файлов нечего восстанавливать...

[заключение.]

Описанный метод восстановления данных страдает кучей ограничений. В частности, при удалении большого количества сильно фрагментированных двоичных файлов, он говорит «пас» и уходит в кусты. Ты только убьешь свое время, но вряд ли найдешь среди обломков файловой системы что-то полезное. Но как бы там ни было, другого выхода просто нет (если, конечно, не считать резервной копии, которой тоже нет).

HTTP://LDE.SOURCEFORGE.NET

LINUX-РЕДАКТОР LDE

HTTP://BIEW.SOURCEFORGE.NET

HEX-РЕДАКТОР BIEW

АВТОМАТИЧЕСКОЕ ВОССТАНОВЛЕНИЕ УДАЛЕННЫХ ФАЙЛОВ ПОД UFS НЕВОЗМОЖНО В ПРИНЦИПЕ

ПРИ НАЛИЧИИ СВОБОДНОГО МЕСТА РЕКОМЕНДУЕТСЯ СОЗДАТЬ КОПИЮ РАЗДЕЛА

ОПИСАННЫЙ МЕТОД ВОССТАНОВЛЕНИЯ ДАННЫХ СТРАДАЕТ КУЧЕЙ ОГРАНИЧЕНИЙ

0


Вы здесь » Still Water » Мир Компьютеров » Как восстановить нечитающийся CD