| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как удалить файл без восстановления [D7]
nikfel © (2008-03-22 11:03:00)Подскажите, пожалуйста. Как удалить файл со всем, чтобы восстановить было нельзя. Заранее спасибо.
Игорь Шевченко (2008-03-23 17:00:00) [81]там автор озабочен удалением мелких файлов :)
guav (2008-03-23 15:29:00) [82]http://www.osronline.com/showThread.cfm?link=54720
Вот интересная ссылка по теме, там автор тоже озабочен удалением и, видимо, не нашел способа "борьбы" с журналированием.
guav (2008-03-23 02:53:00) [83]> [20] Игорь Шевченко © (23.03.08 02:17)
Примерчик чего ?
Читалку логфайла дать не могу.
Про сам логфайл можно прочитать в "Inside Windows 2000".
Опыт подтверждающий восстановимость резидентных файлов через логфайл описан в книге "Криминалистический анализ файловых систем" (там не учтена разбивка логфайла на страницы и необходимость восстановления двух последних байт каждого сектора кадой страницы, но при достаточном везении эти два фактора могут не повлиять и даные будут байт-в-байт как и были). Опыт подтверждащий восстановимость датаранов будет аналогичным. Просто создаём, меняем, ищем в логфайле старый и новый варианты и находим.
Riply (2008-03-23 02:18:00) [84]> [16] Игорь Шевченко © (23.03.08 00:23)
> Пример в студию. Атрибуты файла, как открывала, как писала,
> расположение кластеров до, расположение кластеров после.
> Или ссылки, подтверждающие подобные случаи и/или поведение.
Ссылок разумеется нет, впрочем как и нормальной документации по NTFS.
Соответственно попытка изучить это безобразие(NTFS), в основном, строится на тестах
и изучении их результатов. Их приходиться проводить очень много.
И разумеется, у меня не сохранились ни полное описание
условий, при которых я получила данный результат, ни функций, написанных
спецально для него. Я увидела, что это возможно, сделала себе пометку, "намотала на ус" и пошла дальше :)
Но, чтобы не остаться голословной, я попробую еще раз получить условия, в которых
это воспроизводится более-менее стабильно. Но на это потребуется время.
Так что, придется подождать. Хорошо ?
> До того момента не верю.
И правильно :) Я тоже стараюсь все проверять сама :)
Игорь Шевченко (2008-03-23 02:17:00) [85]guav © (23.03.08 01:22) [19]
Век живи, век учись. Примерчик можно ?
guav (2008-03-23 01:22:00) [86]> [18] Игорь Шевченко © (23.03.08 00:49)
Нет. Но часто живут там достаточно долго.
Логфайл состоит из циклического буфера страниц, т.е. всегда перезаписыватся самые старые.
В NT запись начинается сначала при каждом монтировании, в более новых (2000 и новее) цикл не обрывается и при монтировании/демонтировании.
Игорь Шевченко (2008-03-23 00:49:00) [87]guav © (23.03.08 00:42) [17]
> в NTFS обновления Data Runs всегда журналируются
И живут там вечно ? Мне просто интересно
guav (2008-03-23 00:42:00) [88]> [10] Игорь Шевченко © (22.03.08 22:13)
> Запись как бы скорректирует кластеры, занимаемые файлом,
> нет ?
> Или тв хочешь сказать, что зная кластер на диске, ты гарантировано
> скажешь, какому файлу он принадлежал в прошлом ?
Даже если считать что достаточно разрыва связи между файлом и его данными, в NTFS обновления Data Runs всегда журналируются, поэтому, возможно, связь не будет безнадёжно утеряна в этом случае.
Обычно от надёжного удаления файла хотят преде всего невостановимость самих данных, а не уничтожения информации о файле.
Игорь Шевченко (2008-03-23 00:23:00) [89]Riply © (22.03.08 23:07) [14]
Пример в студию. Атрибуты файла, как открывала, как писала, расположение кластеров до, расположение кластеров после.
Или ссылки, подтверждающие подобные случаи и/или поведение.
До того момента не верю.
Riply (2008-03-22 23:10:00) [90]С заполнением нулями сжатого или разряженного файла, вообще интересно.
Такое впечатление (может и неправильное),
что система может вызвать FSCTL_SET_ZERO_DATA, если ей заблагорассудится :)
А FSCTL_SET_ZERO_DATA может не вести "реальной" записи на диск, а только "подправить" MFT :)
Riply (2008-03-22 23:07:00) [91]> [13] Игорь Шевченко © (22.03.08 22:58)
> Ничего не понимаю - есть файл, у него есть N кластеров.
> Содержимое файла аккуратно заполняется произвольными данными (хотя бы и нулями).
> Он имеет возможность стать дефрагментированым ?
Да.
Я воспроизводила, примерно, такое:
Создавала файл, например, занимающий восемь кластеров с "номерами":
0..3, 128...131.
И после "обычной" записи в него его картинка становилась: 0..7.
Я не утверждаю, что это происходит всегда,
но в моих тестах это повторилось несколько раз.
Игорь Шевченко (2008-03-22 22:58:00) [92]Riply © (22.03.08 22:42) [11]
Ничего не понимаю - есть файл, у него есть N кластеров. Содержимое файла аккуратно заполняется произвольными данными (хотя бы и нулями).
Он имеет возможность стать дефрагментированым ?
Riply (2008-03-22 22:53:00) [93]> [11] Riply © (22.03.08 22:42)
> Но я неоднакратно наблюдала ( и воспроизводила) дефрагментацию файла при записи.
Имеется ввиду на NTFS
Riply (2008-03-22 22:42:00) [94]> [10] Игорь Шевченко © (22.03.08 22:13)
> Ты хочешь сказать, что при записи в файл он дефрагментируется ?
Нет, конечно. Точнее: не такое строгое утверждение.
Но я неоднакратно наблюдала ( и воспроизводила) дефрагментацию файла при записи.
Игорь Шевченко (2008-03-22 22:13:00) [95]Riply © (22.03.08 17:21) [8]
> Более того, если файл, например, исходно был фрагментирован,
> то шансов для этого
> становится очень мало.
Ты хочешь сказать, что при записи в файл он дефрагментируется ?
guav © (22.03.08 19:34) [9]
> Более того писать именно нулями - идея более плохая чем
> писать случайными даными, если файл сжат, то "запись" почти
> ничего не сделает.
Запись как бы скорректирует кластеры, занимаемые файлом, нет ?
Или тв хочешь сказать, что зная кластер на диске, ты гарантировано скажешь, какому файлу он принадлежал в прошлом ?
guav (2008-03-22 19:34:00) [96]> [7] TStas © (22.03.08 16:56)
Уже предложено в [2]. Не будет это работать для всех файлов.
Более того писать именно нулями - идея более плохая чем писать случайными даными, если файл сжат, то "запись" почти ничего не сделает.
Riply (2008-03-22 17:21:00) [97]> [7] TStas © (22.03.08 16:56)
> А почему нельзя получить размер файла, если он > 0, открыть его в режиме
> Чтение/запись и перезаписать нулями? Размер не изменится, а в файле одни нули будут.
> А потом просто deleteFile ему сделать. Вот и удаление без восстановления.
А кто тебе сказал, что "перезаписываемые нули" будут перезаписываться именно
в теже кластеры, где располагался файл ? (Sorry за тавтологию :)
Более того, если файл, например, исходно был фрагментирован, то шансов для этого
становится очень мало.
TStas (2008-03-22 16:56:00) [98]А почему нельзя получить размер файла, если он > 0, открыть его в режиме Чтение/запись и перезаписать нулями? Размер не изменится, а в файле одни нули будут. А потом просто deleteFile ему сделать. Вот и удаление без восстановления.
guav (2008-03-22 14:48:00) [99]Есть подозрение, что на NTFS поможет FSCTL_SET_ZERO_ON_DEALLOCATION, если указывать сразу при создании, не проверял. Но требует Vista.
guav (2008-03-22 14:43:00) [100]> [4] ЦУП © (22.03.08 14:10)
На NTFS нет строгого соотвествия между данными в файле и данными в его кластерах.
Например сжатый файл займёт кластеров меньше чем его размер, тут [2] может не сработать.
Если файл который полностью поместился в MFT, то при перезаписи методом [1] будет повреждена файловая система, при этом файл моет остатьсыя восстановимым. А при перезаписи методом [2] будет востановим. Тут Rouse_ давал ссылку на книгу "Криминалистический анализ файловых систем", там эти тонкости NTFS.
Ну и что уже применимо к любой ФС, следы файла могут быть во всяких темпах, кэшах и свопах. И, при дефрагментации, в старом расположении файла. И ещё есть флешки которые менят маппигн секторов на их физическу память, чтобы распределить "износ" флешки равномерно, тогда затираемый кластер может не совпасть с кластером файла.
| |
Страницы: 