Задача: повредить файл, для обеспечения невозможности его чтения. (И удачного восстановления если его удалить программным способом, на той же машине (тем способом, доступным среднестатистическому пользователю гугл поиска))
Скрытие факта затирания файла - не интересует. Объем файлов и их количество - любое (можно вычислить по ходу)
Вид хранилища - любой (можно вычислить по ходу)
Вид файлов люб...
Какой алгоритм будет считать в себе скорость и эффективность?
Первое что пришло в голову, открыть файл потоком, и пройтись с неким шагом "понатыкивая" нулевые байты. Что можно улучшить?
Код на C#:
private void FileDamage(Stream stream)
{
using (stream)
{
const int upper = 1000;
var step = stream.Length / upper;
if (step == 0) step = 1;
for (long l = 0; l < upper; l++)
{
stream.Seek(step, SeekOrigin.Current);
stream.WriteByte(0);
}
}
}
P. S. Не охото полностью затерать файл (а то и неоднократно). Вопрос состоит в том, что является достаточным в данном случае.
Смотря, что за файл (данные внутри файла) и что для вас значит "невозможность восстановления" и сильно зависит от размера.
"01010101"
и потом второй раз "10101010"
- тогда никто никогда ваши данные не восстановит. Даже из жесткого диска.Помню, в легендарном пакете Norton Utilities были утилиты Wipe, которые затирали данные многократным проходом, с записью разных данных (на радость параноикам).
Также вспоминается Уотергейтский скандал, когда запись на магнитофонной кассете была случайно стёрта секретаршей. И как потом эту запись пытались восстановить.
Из этого можно сделать вывод, что даже стёртую запись можно (попытаться) восстановить. Более того, кроме магнитных носителей есть и оптические, и флэш...
В общем, всё не так просто.
Если бы я писал утилиту для затирания данных, я сделал бы минимум два прохода: один раз все биты записываются нулями, другой раз - единичками. Это, на мой дилетантский взгляд, даст большую степень уверенности, что не останется никаких наводок магнитных полей по краям дорожки (хотя на ленте, хоть на диске).
Это, как мне кажется, справедливо и для магнитных накопителей, и для оптических, и для флэш-памяти (кроме SSD).
SSD - особый разговор. Для уменьшения износа ячеек контроллер может переносить данные на реже используемые ячейки. В итоге, как я понимаю, на накопителе одни и те же данные могут быть физически продублированы. Старая копия затрётся при записи новых данных, но до того момента она есть. И когда мы, казалось бы, затрём свой файл, данные всё равно присутствуют на драйве в предыдущей области. И их можно извлечь, имхо.
Полагаю, тут поможет только полное затирание всего объёма накопителя. Поправьте, если ошибаюсь.
Кофе для программистов: как напиток влияет на продуктивность кодеров?
Рекламные вывески: как привлечь внимание и увеличить продажи
Стратегії та тренди в SMM - Технології, що формують майбутнє сьогодні
Выделенный сервер, что это, для чего нужен и какие характеристики важны?
Современные решения для бизнеса: как облачные и виртуальные технологии меняют рынок
Делаю попытку обнаружения устройств с помощью Bluetooth LE, сделал как написано в этой библиотеке для Xamarin, однако обнаруженных устройств 0
Сортирую список и нужно указать условие что-то вроде если "поле" == null, то сортируй по "поле2", если нет то сортируй по "поле"Как я понял конструкция...
Есть строка, которая может иметь следующий вид, числа в конце строки каждый раз разные: