Бесследное удаление файлов

← →
craZy kurt (2003-12-11 19:02) [0]

Подскажите как бесследно удалить файл с веника. Т.е. чтобы после удаления его нельзя было восстановить. Оч. нужно.

← →
Вася Пупкин (2003-12-11 19:24) [1]

Кувалдой

← →
Юрий Зотов (2003-12-11 19:47) [2]

Ничего не делайте - и добьетесь желаемого. Никаких следов файла на венике не останется. Потому что их там никогда и не было.

← →
Рамиль (2003-12-11 19:54) [3]

Открыть файл и заменить содержимое на байты 00h, потом еще раз на AAh. (Повторять до тех пор, пока не будет уверенности, что достаточно;)) Стереть файл обычным способом.

← →
mrcat (2003-12-11 19:56) [4]

Рамиль © (11.12.03 19:54)
А потом сесть и подумать - а нафига оно мне было надо ? )

← →
Рамиль (2003-12-11 20:03) [5]

Ну, Norton Wipe стирает по описанному алгоритму, так что идея не моя;)

← →
хз (2003-12-11 20:03) [6]

> Подскажите как бесследно удалить файл с веника. Т.е. чтобы
> после удаления его нельзя было восстановить. Оч. нужно.

Создаешь новый раздел, копируешь туда файл, форматируешь раздел, удаляешь раздел. Никаких следов.

← →
mrcat (2003-12-11 20:07) [7]

Рамиль © (11.12.03 20:03)
Да я нисколько и не сомневаюсь. Только тот, кому этот файл "приспичил", не будет дожидаться удаления )

← →
Юрий Зотов (2003-12-11 21:47) [8]

> Рамиль © (11.12.03 20:03) [5]
> Ну, Norton Wipe стирает по описанному алгоритму

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

IMHO, WipeInfo работает гораздо хитрее - она трет данные на ФИЗИЧЕСКОМ уровне.

← →
Игорь Шевченко (2003-12-11 22:02) [9]

Юрий Зотов © (11.12.03 21:47)

> Дело в том, что искореженный файл совершенно не обязательно
> физически запишется в те же кластеры, где находился старый

Нового файла не будет. Будет тот же самый файл, только информация в нем будет сначала 00..., потом AA...
А раз новый файл не создается, то и кластеры останутся теми же самыми.

← →
Nikolay M. (2003-12-11 23:16) [10]

> заменить содержимое на байты 00h, потом еще раз на AAh

Белый шум (т.е. случайное число) еще неплохо бы. А почему AA, а не FF?

← →
SergP (2003-12-12 05:52) [11]

> craZy kurt (11.12.03 19:02)
> Подскажите как бесследно удалить файл с веника. Т.е. чтобы
> после удаления его нельзя было восстановить. Оч. нужно.

Нужно открыть "веник" и поднести к платтерам магнит.

← →
Юрий Зотов (2003-12-12 08:14) [12]

Игорь, действительно не будет нового файла? Если размер файла не меняется, то система действительно пишет его "по месту"?

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

← →
craZy kurt (2003-12-13 00:25) [13]

2 Игорь Шевченко
> А раз новый файл не создается, то и кластеры останутся теми же самыми.

О перезаписи я подумал в первую очередь. Но где гарантия, что новый файл ляжет сверху? У меня заказ горит, а липу впаривать клиенту не хочу. Подскажите чего можно читнуть по этому поводу.

← →
Игорь Шевченко (2003-12-13 00:42) [14]

Юрий Зотов © (12.12.03 08:14)

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

← →
Игорь Шевченко (2003-12-13 00:47) [15]

Юрий Зотов © (12.12.03 08:14)

А авторитетный источник - так все СУБД так работают - у них же файлы с данными на своих местах остаются после модификации.

← →
Anatoly Podgoretsky (2003-12-13 10:25) [16]

Юрий Зотов © (12.12.03 08:14) [12]
Зависит от файловой системе, например на Новеле, сектор всегда пишется на новое место (трансакции), на W9x на старое, на платформе НТ можно ожидать разных сюрпризов, но пока сами данные пишутся на старое место.

← →
Юрий Зотов (2003-12-13 13:09) [17]

> Anatoly Podgoretsky © (13.12.03 10:25) [16]

Если я правильно понял, то имеются в виду не сами W9x и NT, а FAT32 и NTFS? И еще - нет ли подобной информации по Linux?

← →
JibSkeart (2003-12-13 13:22) [18]

del filename > filename :)

← →
Anatoly Podgoretsky (2003-12-13 13:25) [19]

Юрий Зотов © (13.12.03 13:09) [17]
Да именно так не ОС, поскольку большинство ОС поддерживают несколько файловых систем.

Информации у меня нет, но там тоже очень много файловых систем, например мне известно, что Reiser относится к журналируемым и что то по части Ext3 есть, остальные вроде как обычные ФС

← →
Anatoly Podgoretsky (2003-12-13 13:27) [20]

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

← →
mfender (2003-12-13 13:27) [21]

Сильный магнит поможет

← →
Ihor Osov'yak (2003-12-13 14:03) [22]

Хм. Очень это уж тяжелая работа, тянуть из болота бегемота..
Больно недокумемнированные области затрагиваются...
Давай поразмышляем. С одной стороны, транзакционность, как в новеле, очень хороша с точки зрения обеспечения надежности. С другой стороны - такое "новелевское" решение очень будет снижать производительность движков баз, которые новые порции данных пишут "поверх" старых учестков файла, но тех, учестков, которые с их точки зрения, есть свободны. А ОС о том, что эти области "свободны" может не знать, и в случае "нобелевского" стиля, будет пытаться "затранзикцировать" мусор.. К чему это я.. Думаю, рано или поздно начнется миграция в сторону новелевского стиля, все - же надежность, но наверно будет введен некий слабо документированный вызов, который будет отключать этот механизм "транзакционности" на уровне сектора для отдельно взятых файлов, так как для СУБД, которые сами управляют распределением дискового пространства в пределах тела своего файла - такая транзакционность будет быстрее всего помеха, а не помощь..
Так что я думаю, что MS может с очень большой вероятностью вносить изменения в механизм распределения секторов.. И то, что верно сегодня, может стать неверным завтра после очередного сервис пака..
И еще вспомним сжатые файлы... Был, например сектор, с инфо, очень поддающейся сжатию. А переписали мы его почти рандомной. После сжатия ему потребуется намного больше места, чем вначале. И вряд ли он запишется на старое место (по причине отсутствия пространства).

А для любителей покопаться – sysinternals, благо diskmon есть и для NT ряда, и для W9x, и для Linux

Да. Я понимаю, что это всего лишь рассуждения, но я бы не стал полагаться на то, что “сектора” при переписывании будут “всегда” “ложиться на старое место”. Имхо, гарантии этого не даст даже Бил, не то, что Игорь Шевченко

Бесследное удаление файлов Найти похожие ветки