Восстановление перезаписанных файлов
 

Не нашел вроде подходящую ветку, спрошу здесь:

Фаил (база аксесса .mdb) был перезаписан файлом с тем же именем, то есть в 2-х каталогах были разные файлы с одинаковым именем, надо было переписать с первого каталога во второй, а переписали случайно из второго в первый. Теперь надо восстановить файл из первой папки; никакие программы, пробовал штук 8, что восстанавливают из удаленных, форматированных, переустановленных и чуть ли не с украденных дисков, ничего не обнаружили.

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

Есть какой-нибудь метод выхода из этой ситуации?

К сожалению, нет, представьте себе File.doc с десяться страницами, который перезапишется тем же файлом File.doc с одной страницей. Возможно ли будет вернуть перезаписаному файлу File.doc недостающие 9 страниц? Я думаю нет.

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

Ну разве только если новый File.doc запишется на на том же месте; по моему так и есть, не может система сделать такую глупость, но тем не менее найти старый файл невозможно почему-то.

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

Нет, не думаю.

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

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

Так Access всегда работает с оригинальной базой данных, а не с копией и вносит изменения прямо в неё.

maxo Гы, попробуйте самостоятельно написать ОС, причём сложную и сразу без ошибок...
А файл на старом месте расположить проще всего, особенно если он меньше того, который располагался там же ранее. И всего-то приписать в конце файла EOF (End Of the File).

Drongo,
Access–то работает, файловая система не может работать таким образом. Файл просто переписали с одной папки в другой, Access тут непричем.

DVDshnik,
Не вижу резона, почему файл на старом месте расположить проще всего, тем более что не о простоте в данном случае будет думать человек, писавший ФС (а не ОС, который тут также непричем).


Ладно, мы увлеклись, а вопрос открыт.
Ну неужели никто с такой проблемой не сталкивался?

ONTRACK EASY RECOVERY!!! Вот эта прога тебе поможет...... тама заходишь в подменю "восстановление файлов" >>> восстаналение ms access...

Если бы все было так просто!
Конечно, большинство сталкивалось, и в лучшем случае, процентов 5-10 оказались везунчиками и вытащили данные.
Дело ведь не в программе, их предостаточно, а в том, что на момент работы программы восстановления, данные уже (в подавляющем большинстве случаев) перезаписаны.
Упрощенно, что произошло в вашем случае:
- сначала системой был удален перезаписываемый файл. Фактически он остался на месте, а удалился в таблице расположения файлов, место занимаемое им на диске стало свободным.
- затем записался новый файл, ссылка на него появилась в таблице расположения файлов, а данные записаны в области диска, взятой из свободной.
Если при записи данных нового файла не были затронуты (даже частично, пример Drongo) данные удаленного файла в свободной области - восстановление возможно, в противном случае - не поможет никакая прога, поскольку данные некондиционны.
Правильно, но не всегда помогает, система многозадачная, могли записываться данные журналов, файла подкачки, приложения или службы могли писать временные файлы и т.п.
Тут уж как повезет.

ab57,

Ну вот и не повезло :(

Дело в том, что система не сразу использует освободившееся пространство, а старается выслать "подальше" (так я когда-то читал в описании файловой системы).
На том диске 70% места свободно; не могла система переписать на том же месте, тем более что не думаю что система (файловая) сначала стирает старый файл, а потом пишет новый - скорее она блокирует его (и то не всегда), пишет новую и потом удаляет из таблицы.

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

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

Думаю, обнаружен самы надежный способ удаления информации (а это - доволно сложная проблема) :). Зря там некоторые специальные программы для этого пишут и что-то выдумывают :) .

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

Это так? :unsure:

Да.
На уровне файловой системы единицой адресации дискового пространства является кластер - группа последовательных секторов диска.
Когда файл создается, в таблице расположения файлов (она различается для FAT, FAT32, NTFS, но принцип тот же) создается запись, где хранится имя файла, размер, адрес расположения собственно данных.
При удалении файлов изменяется только эта запись, файл помечается как удаленный, а адреса данных расположения бывшего файла становятся свободными.
Если при записи какого-либо нового файла будет использована область, ранее принадлежавшая удаленному файлу, то восстановление будет невозможно.

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

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

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

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

Вы ошибаетесь. Если бы это было так, то в каталоге в один и тот же момент времени присутствовало 2 файла с одинаковым именем ("захваченный" и вновь записываемый). Данные не могут записываться в никуда, сначала создается запись о файле в таблице расположения файлов.
Как это работает на самом деле, можно проверить с помощью утилиты мониторинга файловых операций FileMon.exe.
При перезаписи файла используется функция "Create" (колонка Request) с опциями Overwriteelf Sequential. При выполнении Create, если файл уже существует, его длина устанавливается в ноль, а указатель данных - на свободную область раздела. После Create выполняется функция "Set Information" и длина нового файла устанавливается равной длине копируемого. И только после этого выполняется само копирование данных последовательностью функций READ для копируемого и WRITE для нового файла.

ab57,
Мог бы и сдаться, конечно :)

Но терзают смутные сомнения:

А что произайдет, если:
1. Будет сбой при записи файла?
2. Пользователь прервет операцию?
3. При процессе будет инициирован новый процесс записи файла с тем же именем?

Эти программы пробовали?
UndeleteMyFiles
Recuva http://recuva.com/
Важно не устанавливать программы на тот же диск, откуда восстанавливаются данные.
Если новый файл меньше, то, по логике, не все сектора будут перезаписаны.
Однако начало файла будет утеряно, следовательно, его целостность будет нарушена.
Не знаю, возможен ли такой глубокий анализ и восстановление, так что не скажу.

maxo, сомнения в нашей профессии - вещица полезная.
Эти же сомнения терзали и разработчиков операционок.
Поэтому и появился программный интерфейс (API), обеспечивающий доступ приложений к файловой системе не напрямую, а через запросы к модулям API (модули служб, библиотеки ядра, драйверы). Кроме своего прямого назначения, вроде чтения/записи файлов и т.п. API решает еще одну важную задачу, - обеспечить работоспособность системы, даже если программа написана с ошибками, возникли сбои оборудования, у юзера крыша поехала и т.д.
По-этому:
1. Если будет сбой при записи файла, API сообщит об этом приложению, а приложение окончательно решит, что делать с данными (наверно не раз приходилось видеть запрос к юзеру выбрать действие - Abort, Retry, Ignore). Наиболее распространенное действие приложения - отмена операции при неисправимой ошибке- запись прекращается и файл удаляется.
2. Аналогично п 1.
3. Если файл открыт на запись, то он блокируется API и функция создания файла с таким же именем (CREATE ) завершится ошибкой, даже если установлена опция перезаписи (OverWrite).

В таком случае пропадет и старый и новый файл.
И что главное - так и есть на самом деле. К моему большому удивлению.
Я поекспериментировал от нечего делать - начал перзапись файла с другим одноименным, потом прервал операцию, и нет не старого не нового.

Но это НЕ правильно, это глупо! Даже допотопная система RT11 (по-советскому Рафос) так не делал.

Вы правы, однако :dont-know

Мне это тоже не нравится. :o
Еще один плюсик FAR'у. Если найдете время, попробуйте повторить ваши действия в FAR'е - все должно получиться как надо. Возможно и в Total Commander'e тоже.

Как WinXP ведет себя при перезаписывании файла в FAT32?
 

Короче, 2 файла Excel'я с одинаковыми названиями. Один новый, другой старый. Случайно новый файл заменили старым.
Пытались восстановить с помощью R-studio и EasyRecovery. Нашли 20 штук всего разного, но всё от старого файла или вообще кашамалашу. Короче восстановить не удалось. А с момента казуса HDD тут же отключили.

Посему вопрос: WinXP когда перезаписывает файл, он не затирает его? Файловая система FAT32

lem785, к сожалению, вряд ли получится восстановить файл :(
Попробуйте еще программы UndeleteMyFiles и Recuva.

Жаль... Отправил человека считать склад...
Но после прочтения темы, вопрос остался все равно не ясен: при перезаписи файла в несколько кластеров по 32к, данные записываются на место(ну или затрагивая это место) прежнего файла?

lem785, похоже, что при перезаписи система даже если и не затрагивает кластера, занимаемые "старым" файлом, все равно его не удастся восстановить программами-рековерами, поскольку эти программы ищут стертые файлы в ФАТ-е, а там при обычной стирании (и даже удалении из ресайкла) все-равно остается запись об этом файле, хоть и "не активная", так что файл-менеджеры ее не видят, а эти программы увидят и проследуют по пути, указанной в записи (короче, в ФАТ-е записывается имя файла, дата создания, аттрибуты, некий признак "активности", и адрес первого кластера, занимаемого файлом. В этом кластере записан данные от файла, и если данные больше 1 кластера, файл продолжается в другом кластере, адрес которого содержит тот-же первый кластер; второй кластер, если надо, будет содержать адрес третьего и так далее). Когда система просто стирает файл, запись о файле не уничтожается, а просто меняется признак "активности" так, чтоб этот файл не было видно в файл-менеджере, а программа-рековер, просматрывая ФАТ, увидит такой файл и "соберет" все его кластеры, т. е. восстановит файл.

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

Во сколько написал! Хорошо сидеть на совещании :)

О, благодарю за столь полный ответ! =)
А разве нет программ, осуществляющих поиск не по заголовку, а по содержанию файла напрямую через диск? Хотя бы примитивных текстовых.
А как насчет NTFS, та же история?

Кстати, во времена Windows 98 была такая программа (вроде бы) "Norton Protected Recycle Bin". Как-то так называлась.
Так вот она создавала Корзину, которая подхватывала любые удаленные файлы, в т.ч. удаленные программами.
Этим она страховала пользователя от нежелательного удаления.
Сейчас такого нет?

Есть, но по отдельности не встречалась, только в составе пакетов "Norton System Works" "Norton Antivirus". Насчет последнего - до NAV2004 было такое, а в дальнейших версиях - не знаю. В случае maxo, эта штука, пожалуй, данные бы спасла.
Технология "Norton Protected Recycle Bin" была построена на перехвате системных вызовов для удаления файлов, и перемещении их в специальную зону, скрытую от Windows API, т.о. при удалении данные копировались и становились как бы невидимыми для приложений. Само удаление из этой зоны выполнялось с задержкой на несколько дней. Технология в целом неплохая, но работает постоянно, а необходимость вытащить удаленные данные возникает очень редко или вообще никогда, вот и не получила особого признания.

Относительно файлов word и excel решил проблему в своей теме "Резервное копирование файлов doc и xls" при помощи программы MSOBackup.
Однако, если перезаписанный файл не открывался на компьютере, то и в резервную базу он еще не успел попасть.
Ее можно установить без Norton Antivirus?

Проекспериментировал и я от нечего делать:
1) Windows Server 2003.
2) Одноименные файлы разных версий на разных логических дисках,
если на одном, то я не успевал создавать аварийную ситуацию.
3) Условимся с терминами:
актуальный файл - файл который нельзя потерять,
старый файл - старая версия с таким же именем как актуальный файл.
4) Действие: перемещаем по ошибке старый файл в папку с актуальным файлом:
а) в процессе переноса нажимаем отменить, результат актуальный файл исчезает, но старый файл остается.
Подтверждаю, актуальный файл программой FileScavenger не восстанавливается.
б) в процессе переноса нажимаем ресет, результат актуальный файл остается, но уже не совпадает ни со старым файлом, ни с самим собой до аварии. Полагаю, что если быстро одуматься и перезагрузить компьютер, то большую часть информации можно вытянуть.
В обоих случаях старый файл остается нетронутым.
Мне инетересно знать как у maxo получилось удалить старый файл?

dzekka,

С переносом может быть другие нюансы. В моем случае файл не переносили, а копировали с одной папки в другую. Естественно, в П1 файл в любом случае останется - хоть при удачном, хоть неудачном окончании операции. А вот в П2 - при удачном получаем старый файл, а актуальный пропадает и не восстановливается. при неудачном копировании (вернее при отмене пользователем, ресет и другие аварии не пробовал) - пропадает и старый и актуальный (пробовал как с ВФМ так и тоталом), и тоже не восстанавливается.

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

Все верно, и так и должно быть по идее - 2 файла с одинаковым именем но с разными признаками (например, "блокированный" и "временный", и обе невидимые пользователю, в отличии от "активных"), это и защищало бы "местный" файл в случае неудачи. Ведь в каталоге одинаковые файлы мы не можем записать потому, что ФС это запрещает, а самому ФС никто не запрещает "припрятать" этот "местный" файл до окончания операции (открывая "временный" файл с тем же именем) и удалить его ТОЛЬКО после удачного завершения (сделать его "стертым", а пришельца-"временного" - активным), а вслучае неудачного - просто его восстановить (сделать "блокированный" активным, а "временный" - стертым) и все будет как будто никто ничего не перезаписывал. Это и непонятно почему ФС режет себе обратную дорогу.

Я был не правильно понял, подумал, что у вас с обоих панелей файл пропадал.

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

Что системе делать, если на "припрячивание" файла нет места на диске?
Так что алгоритм "а) стереть; б) скопировать" вполне правилен.
Хотя конечно было бы здорово, чтобы система была умной и при возможности припрятывала файлы.
А еще было бы здоровее, чтобы в системе уже был встроенный механизм восстановления,
чтобы не перебирать на одном стертом файле десять утилит...