| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как удалить файл без восстановления [D7]
nikfel © (2008-03-22 11:03:00)Подскажите, пожалуйста. Как удалить файл со всем, чтобы восстановить было нельзя. Заранее спасибо.
Riply (2008-03-27 12:08:00) [21]> [80] Игорь Шевченко © (27.03.08 11:51)
> Ты забыла указать, у тебя при этом, при "обычной" записи, параллельно кластеры перемещались ?
> Явно твоим процессом или дефрагментатором.
Тогда я вела запись процедурой, аналогичной WipeFileBySchevchenko,
только не циклом, а буфером размером равным размеру файла.
Дефрагментатор запущен не был.
Насчет пермещающих кластеры процессов ничего сказать не могу.
Моих не было, а вот не мои могли быть
(например, стояли Norton Unerase, DAEMON Tools может еще что. Не помню).
Это те, на кого может пасть подозрение.
Тогда я о других процессах и не думала.
Я полагала, что это может делать только система и никто более,
соответственно не обращала внимания на то, кто еще работает.
guav (2008-03-27 12:07:00) [22]> [82] Игорь Шевченко © (27.03.08 12:00)
Я понимаю что не спортивно. Просто пример, что затереть не так просто :)
Чтобы устранить указаную в [81] проблему, в затиралках используют FILE_FLAG_NO_BUFFERING.
Я самопроизвольное перемещение наблюдал только на сжатых файлах.
Игорь Шевченко (2008-03-27 12:00:00) [23]guav © (27.03.08 11:55) [81]
> Соотвественно того же можно достичь не удаляя файл, а просто
> чита его через прямой доступ к тому сразу после затирания.
>
А можно просто скопировать его перед тем, как затереть :) Возни меньше.
guav (2008-03-27 11:55:00) [24]> [73] clickmaker © (27.03.08 10:37)
> что нельзя так затереть файл, чтобы не было возможности
> восстановить?
Я бы так сказал, что, скорее всего, простая перезапись приведёт к тому, что файл не будет восстановим. Но "скорее всего" может быть недостаточно, тогда затереть гарантировано может быть сложно. Нужно учитывать кучу всего.
Например, если после кода [54] файл сразу удалить, то файл может быть восстановим - запись происходит не сразу, может так получиться, что на момент записи писать будет уже некуда и незачем. Соотвественно того же можно достичь не удаляя файл, а просто чита его через прямой доступ к тому сразу после затирания.
Игорь Шевченко (2008-03-27 11:51:00) [25]Riply © (27.03.08 11:47) [79]
> Я напомню из поста [14]
>
> "Я воспроизводила, примерно, такое:
> Создавала файл, например, занимающий восемь кластеров с
> "номерами":
> 0..3, 128...131.
> И после "обычной" записи в него его картинка становилась:
> 0..7.
> Я не утверждаю, что это происходит всегда,
> но в моих тестах это повторилось несколько раз."
Ты забыла указать, у тебя при этом, при "обычной" записи, параллельно кластеры перемещались ? Явно твоим процессом или дефрагментатором.
Riply (2008-03-27 11:47:00) [26]> [78] Игорь Шевченко © (27.03.08 11:39)
> Пример в студию, когда при обычной записи и при отсутствие процесса, перемещающего кластеры,
> распределение кластеров может измениться при перезаписи по месту несжатого и неразреженного файла.
Игорь, так я же в том утверждении написала: "А кто тому виной ... ответить не готова."
Я имела ввиду, что не знаю кто перемещал "процесс, перемещающий кластеры" или система.
Sorry, если непонятно выразилась.
Игорь Шевченко (2008-03-27 11:39:00) [27]Riply © (27.03.08 10:19) [72]
Пример в студию, когда при обычной записи и при отсутствие процесса, перемещающего кластеры, распределение кластеров может измениться при перезаписи по месту несжатого и неразреженного файла.
Riply (2008-03-27 11:24:00) [28]> [76] clickmaker © (27.03.08 11:18)
> ну так, и документ, скормленный шредеру, тоже можно восстановить при желании )
> только кому это интересно, кроме налоговой и ГРУ? )
Ну... например, возможно, автор этой ветки, полагает, что за его данными может
охотиться одна из этих благославенных организаций :)
clickmaker (2008-03-27 11:18:00) [29]
> [75] Riply © (27.03.08 11:03)
ну так, и документ, скормленный шредеру, тоже можно восстановить при желании )
только кому это интересно, кроме налоговой и ГРУ? )
Riply (2008-03-27 11:03:00) [30]> [73] clickmaker © (27.03.08 10:37)
> а о чем речь вообще?
> что нельзя так затереть файл, чтобы не было возможности восстановить?
Обо всем понемножку. И об этом, в том числе :)
Точнее не "нельзя", а очень сложно :)
Riply (2008-03-27 11:01:00) [31]> [70] Riply © (27.03.08 10:00)
> Единственное, что могу утверждать, что "переезд" во время записи возможен.
Чуть подумав, изменю формулировку:
"возможен "переезд" во время работы цикла while Condition do WriteFile"
Ибо именно это происходит в моем примере.
clickmaker (2008-03-27 10:37:00) [32]а о чем речь вообще?
что нельзя так затереть файл, чтобы не было возможности восстановить?
Riply (2008-03-27 10:19:00) [33]> [71] Игорь Шевченко © (27.03.08 10:14)
> Пример в студию
Тот, который я описывала выше ?
Мне понадобится время для написания кода, пригодного к компиляции.
Игорь Шевченко (2008-03-27 10:14:00) [34]
> Единственное, что могу утверждать, что "переезд" во время
> записи возможен.
Пример в студию
Riply (2008-03-27 10:00:00) [35]> [69] Игорь Шевченко © (27.03.08 09:46)
> У меня небольшой вопрос, что значит "обычной" записи в твоих словах ?
> С параллельно работающим дефрагментатором или иной перемещалкой кластеров ?
Игорь, к сожалению, я не могу дать четкого ответа.
В то время мне и голову не приходило, что кто-то кроме системы может это делать.
Едиственное, что могу сказать: дефрагментатор точно не был запущен :)
Насчет других "перемещалок кластеров" не уверена.
Например, я не знаю как работает "DAEMON Tools". (тогда он у меня стоял).
Что было еще не помню. "Norton Unerase" может ?
Соответственно не могу дать однозначного ответа и на это вопрос:
> Обычный диск, на нем обычная система NTFS, параллельно не запущено пермещающих кластеры процессов.
> Возможна ли ситуация, когда при записи файла (не сжатого, не разреженного)
> по месту, его распределение кластеров поменяется ?
Единственное, что могу утверждать, что "переезд" во время записи возможен.
А кто тому виной ... ответить не готова. (Пока :)
P.S.
Есть один вариант теста... Надо хорошенько его обдумать.
Может он и поможет нам докапаться ло истины :)
Игорь Шевченко (2008-03-27 09:46:00) [36]Riply © (27.03.08 02:10) [68]
> К сожалению, я не знаю как поведет себя система. Ибо неисповедима
> :)
Система вполне исповедима бо написана согласно детерминированным алгоритмам.
Я напомню из поста [14]
"Я воспроизводила, примерно, такое:
Создавала файл, например, занимающий восемь кластеров с "номерами":
0..3, 128...131.
И после "обычной" записи в него его картинка становилась: 0..7.
Я не утверждаю, что это происходит всегда,
но в моих тестах это повторилось несколько раз."
У меня небольшой вопрос, что значит "обычной" записи в твоих словах ?
С параллельно работающим дефрагментатором или иной перемещалкой кластеров ?
> В такой постановке, это довольно не просто.
> Этим процессом может оказаться драйвер, какого нибудь супер-
> пупер виртуального диска.
> Но я буду иметь это ввиду и постоянно следить не имело ли
> это место.
> Благо работаю то с файловой системой.
Обычный диск, на нем обычная система NTFS, параллельно не запущено пермещающих кластеры процессов. Возможна ли ситуация, когда при записи файла (не сжатого, не разреженного) по месту, его распределение кластеров поменяется ?
Riply (2008-03-27 02:10:00) [37]> [67] Игорь Шевченко © (27.03.08 01:33)
> Да, если при этом работает дефрагментатор, то тоже не является фактом.
> Только я, убей бог, не понимаю, что это значит ?
Это означает то, что ответ "записать в файл нули" на вопрос
"Как удалить файл со всем, чтобы восстановить было нельзя?"
является не совсем корректным. Только и всего :)
> Что система может произвольно при записи перераспределить кластеры файла ?
> Нет, их перераспределит ТВОЙ ПРОЦЕСС или процесс дефрагментатора, но никак не система сама собой.
К сожалению, я не знаю как поведет себя система. Ибо неисповедима :)
Вдруг она решит, что при записи именно в такой то файл, ей удобнее работать так-то и так-то. Черт ее знает :)
> Если ты добьешься того, что при отсутствии параллельных процессов, перемещающих кластеры файла,
> система будет их перераспределять при записи того же файла по месту,
> тогда пост о том, что "кластеры могут меняться" будет считаться действительным.
В такой постановке, это довольно не просто.
Этим процессом может оказаться драйвер, какого нибудь супер-пупер виртуального диска.
Но я буду иметь это ввиду и постоянно следить не имело ли это место.
Благо работаю то с файловой системой.
P.S.
Я могу не знать, ошибаться, не понимать чего-то, но никак не передергивать или подтасовывать факты.
P.P.S.
И вообще, у меня очень спортивное поведение.
Решила объявить это сама, а то вдруг кто не догадается :)
Игорь Шевченко (2008-03-27 01:33:00) [38]Riply © (27.03.08 01:14) [66]
> Во всяком случае показано, что при обычной записи в файл,
>
> не является фактом ведение записи именно в те кластеры где
> этот файл располагался.
Да, если при этом работает дефрагментатор, то тоже не является фактом.
Только я, убей бог, не понимаю, что это значит ?
Если параллельно с записью происходит копирование файла, то тоже не факт, что копия будет идентична оригиналу.
И что из этого следует ? Что не надо затирать файлы, когда их одновременно копируют ? Что система может произвольно при записи перераспределить кластеры файла ?
Нет, их перераспределит ТВОЙ ПРОЦЕСС или процесс дефрагментатора, но никак не система сама собой.
Если ты добьешься того, что при отсутствии параллельных процессов, перемещающих кластеры файла, система будет их перераспределять при записи того же файла по месту, тогда пост о том, что "кластеры могут меняться" будет считаться действительным.
Этак каждый гражданин себе веревок настрижет, польт не напасешься.
Riply (2008-03-27 01:14:00) [39]> [65] Игорь Шевченко © (27.03.08 00:26)
Еще раз попробую снять обвинение в неспортивом поведении :)
> Под "делать все, что хочешь", я, разумеется не имел в виду создание копии незатертых данных.
О какой копии идет речь ? Пока не начался цикл затирания, я даже файл не открываю.
Только после этого получаю Pointers даю команду на перемещение.
К этому времени в цикле уже обработана чать данных.
Было бы нелогично предполагать, что система будет перемещать старые(уже никому не нужные данные),
чтобы потом их затирать. Она просто скинет уже обработанные данные в новое место и продолжит запись
в новые кластеры. (Мой первый пример подтверждает это предположение)
Так что копии, в данном случае, не создается, а только переопределяется место записи. (Это надеюсь спортивно ? :)
Здесь, конечно, мне попалась облегченная задача.
Если бы буфер для затирания был не 1024, а равен кластеру,
еще лучше "объединению" кластеров (обычно это 16 кластеров), то было бы сложнее, но не безнадежно :)
Трудности возникли бы и с большими файлами.
Но мы же искали не способ затирания, а контрпример.
И с этой задачей, как мне кажется, нам удалось справиться.
Во всяком случае показано, что при обычной записи в файл,
не является фактом ведение записи именно в те кластеры где этот файл располагался.
Игорь Шевченко (2008-03-27 00:26:00) [40]
> Нет, не так получается, а вот как: я вынуждаю функцию затирать
> не те кластеры, где располагался файл,
> а новые, совершенно другие. Что она с успехом и делает :
> )
> И считываю я не из "скопированных класеров" а из "старых",
> которые в результате
> остались на диске безхозными и не затертыми. :)
Ну я говорю, проще скопировать файл перед затиранием. Неспортивно.
Под "делать все, что хочешь", я, разумеется не имел в виду создание копии незатертых данных.
| |
Страницы: 