Показать полную графическую версию : Восстановление перезаписанных файлов
maxo, сомнения в нашей профессии - вещица полезная.
Эти же сомнения терзали и разработчиков операционок.
Поэтому и появился программный интерфейс (API), обеспечивающий доступ приложений к файловой системе не напрямую, а через запросы к модулям API (модули служб, библиотеки ядра, драйверы). Кроме своего прямого назначения, вроде чтения/записи файлов и т.п. API решает еще одну важную задачу, - обеспечить работоспособность системы, даже если программа написана с ошибками, возникли сбои оборудования, у юзера крыша поехала и т.д.
По-этому:
1. Если будет сбой при записи файла, API сообщит об этом приложению, а приложение окончательно решит, что делать с данными (наверно не раз приходилось видеть запрос к юзеру выбрать действие - Abort, Retry, Ignore). Наиболее распространенное действие приложения - отмена операции при неисправимой ошибке- запись прекращается и файл удаляется.
2. Аналогично п 1.
3. Если файл открыт на запись, то он блокируется API и функция создания файла с таким же именем (CREATE ) завершится ошибкой, даже если установлена опция перезаписи (OverWrite).
1. Если будет сбой при записи файла, API сообщит об этом приложению, а приложение окончательно решит, что делать с данными (наверно не раз приходилось видеть запрос к юзеру выбрать действие - Abort, Retry, Ignore). Наиболее распространенное действие приложения - отмена операции при неисправимой ошибке- запись прекращается и файл удаляется.
2. Аналогично п 1. »
В таком случае пропадет и старый и новый файл.
И что главное - так и есть на самом деле. К моему большому удивлению.
Я поекспериментировал от нечего делать - начал перзапись файла с другим одноименным, потом прервал операцию, и нет не старого не нового.
Но это НЕ правильно, это глупо! Даже допотопная система RT11 (по-советскому Рафос) так не делал.
Вы правы, однако :dont-know
Но это НЕ правильно, это глупо! »
Мне это тоже не нравится. :o
Еще один плюсик FAR'у. Если найдете время, попробуйте повторить ваши действия в FAR'е - все должно получиться как надо. Возможно и в Total Commander'e тоже.
Короче, 2 файла Excel'я с одинаковыми названиями. Один новый, другой старый. Случайно новый файл заменили старым.
Пытались восстановить с помощью R-studio и EasyRecovery. Нашли 20 штук всего разного, но всё от старого файла или вообще кашамалашу. Короче восстановить не удалось. А с момента казуса HDD тут же отключили.
Посему вопрос: WinXP когда перезаписывает файл, он не затирает его? Файловая система FAT32
lem785, Темы склеил, прочитайте тему с начала.
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, т.о. при удалении данные копировались и становились как бы невидимыми для приложений. Само удаление из этой зоны выполнялось с задержкой на несколько дней. Технология в целом неплохая, но работает постоянно, а необходимость вытащить удаленные данные возникает очень редко или вообще никогда, вот и не получила особого признания.
2 файла Excel'я с одинаковыми названиями. Один новый, другой старый. Случайно новый файл заменили старым. »
Относительно файлов word и excel решил проблему в своей теме "Резервное копирование файлов doc и xls" (http://forum.oszone.net/post-1598258.html) при помощи программы MSOBackup.
Однако, если перезаписанный файл не открывался на компьютере, то и в резервную базу он еще не успел попасть.
Norton Protected Recycle Bin ... Само удаление из этой зоны выполнялось с задержкой на несколько дней.»
Ее можно установить без Norton Antivirus?
Я поекспериментировал от нечего делать - начал перзапись файла с другим одноименным, потом прервал операцию, и нет не старого не нового.
Но это НЕ правильно, это глупо! Даже допотопная система RT11 (по-советскому Рафос) так не делал. »
Проекспериментировал и я от нечего делать:
1) Windows Server 2003.
2) Одноименные файлы разных версий на разных логических дисках,
если на одном, то я не успевал создавать аварийную ситуацию.
3) Условимся с терминами:
актуальный файл - файл который нельзя потерять,
старый файл - старая версия с таким же именем как актуальный файл.
4) Действие: перемещаем по ошибке старый файл в папку с актуальным файлом:
а) в процессе переноса нажимаем отменить, результат актуальный файл исчезает, но старый файл остается.
Подтверждаю, актуальный файл программой FileScavenger не восстанавливается.
б) в процессе переноса нажимаем ресет, результат актуальный файл остается, но уже не совпадает ни со старым файлом, ни с самим собой до аварии. Полагаю, что если быстро одуматься и перезагрузить компьютер, то большую часть информации можно вытянуть.
В обоих случаях старый файл остается нетронутым.
Мне инетересно знать как у maxo получилось удалить старый файл?
dzekka,
С переносом может быть другие нюансы. В моем случае файл не переносили, а копировали с одной папки в другую. Естественно, в П1 файл в любом случае останется - хоть при удачном, хоть неудачном окончании операции. А вот в П2 - при удачном получаем старый файл, а актуальный пропадает и не восстановливается. при неудачном копировании (вернее при отмене пользователем, ресет и другие аварии не пробовал) - пропадает и старый и актуальный (пробовал как с ВФМ так и тоталом), и тоже не восстанавливается.
Получается, что при перезаписи файла другим одноименным этот файл удаляется лучше (или хуже - это как посмотреть :) ), чем просто при удалении. Причем сама операция перезаписи начинается с такого удаления, что и удивляет (и возмущает).
Если бы это было так, то в каталоге в один и тот же момент времени присутствовало 2 файла с одинаковым именем »
Все верно, и так и должно быть по идее - 2 файла с одинаковым именем но с разными признаками (например, "блокированный" и "временный", и обе невидимые пользователю, в отличии от "активных"), это и защищало бы "местный" файл в случае неудачи. Ведь в каталоге одинаковые файлы мы не можем записать потому, что ФС это запрещает, а самому ФС никто не запрещает "припрятать" этот "местный" файл до окончания операции (открывая "временный" файл с тем же именем) и удалить его ТОЛЬКО после удачного завершения (сделать его "стертым", а пришельца-"временного" - активным), а вслучае неудачного - просто его восстановить (сделать "блокированный" активным, а "временный" - стертым) и все будет как будто никто ничего не перезаписывал. Это и непонятно почему ФС режет себе обратную дорогу.
Естественно, в П1 файл в любом случае останется - хоть при удачном, хоть неудачном окончании операции.»
Я был не правильно понял, подумал, что у вас с обоих панелей файл пропадал.
при неудачном копировании (вернее при отмене пользователем, ресет и другие аварии не пробовал) - пропадает и старый и актуальный (пробовал как с ВФМ так и тоталом), и тоже не восстанавливается. »
На досуге поэкспериментирую.
Думается есть надежда, что при своевременной отмене копирования актуальный файл может быть частично восстановлен. Конечно во многих случаях такое частичное повреждение файла приведет к полной непригодности всего восстановленного.
Причем сама операция перезаписи начинается с такого удаления, что и удивляет (и возмущает). »
Что системе делать, если на "припрячивание" файла нет места на диске?
Так что алгоритм "а) стереть; б) скопировать" вполне правилен.
Хотя конечно было бы здорово, чтобы система была умной и при возможности припрятывала файлы.
А еще было бы здоровее, чтобы в системе уже был встроенный механизм восстановления,
чтобы не перебирать на одном стертом файле десять утилит...
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.