freepascal.ru

Как же всё-таки удалить файл без "хвостов"?
Этот вопрос косвенно уже поднимался в теме "Как предотвратить восстановление удалённых данных?" viewtopic.php?f=13&t=11094. Дело в том, что если заменить содержимое файла, допустим, нулями, а затем выполнить удаление (сразу же или через несколько минут), то на диске сохраняется первоначальный текст. Если же в промежуток времени, между заменой содержимого и удалением открыть этот файл, например, "Блокнотом", то на диске остаются только нули. Причём во всех секторах. Специально сделал несколько относительно больших файлов, которые OC разбросала по всему диску, и проверял WinHex-ом.
Посоветуйте, как можно решить эту задачу?
У меня есть одна идея, связанная с запуском между заменой содержимого и стиранием чего-то типа "Блокнота", но может есть лучший вариант...

Ты флушнул записанное перед этим? Желательно через API ОС (FlushFileBuffers на TFileStream.Handle). Всё равно может не сработать, как и чтение из другого процесса: слишком много слоёв абстракции, каждый из которых норовит что-то закешировать и оптимизировать. Так, задним числом можно предположить, что да, запросы к файлу, который всё равно предполагается тут же удалить, до физического устройства не доходят.

Ага, открыть файл повторно самому

Ты флушнул записанное перед этим?

Нет. Я открываю файл средствами FPC без прямого использования API. Надо попробовать.

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

debi12345 писал(а):Хоть один сектор файла затрется нулями - информация в других секторах станет полным мусором.

вообще-то не совсем так. просто трудоемкость возрастает.

вообще-то не совсем так.

Один сектор, реально принадлежавший файлу, по-любому затрется - либо при забивании нулями, либо когда будет отдан другому файлу или каталожной структуре. Поэтому думаю что 100% надежное решение.

Попробовал в интервале между затиранием и стиранием запускать другое приложение через TProcess. Эффект нулевой: в файловой системе файл удаляется, а всё содержимое остаётся на диске. Вероятно, ОС зная, что это дочерний процесс, не сбрасывает на физический диск данные.

Попробовал в интервале между затиранием и стиранием

Шифруйте файл в рабочем режиме, а перед удалением затирайте без шифрования - должно помочь!

в файловой системе файл удаляется

Это еще зависит от файловой системы - FAT, NTFS, Ext,.. - поэтому вообще нельзя закладываться на сброс буферов и т.п.

Добавлено спустя 5 минут 2 секунды:
На само деле если кому-то ну ооочень надо прочитать этот файл, то он может тупо нажать "резет" во время работы проги - чтобы прога не успела удалить файл, и после перезагрузки...

debi12345 писал(а):Поэтому думаю что 100% надежное решение.

но данные то восстановить реально.пусть частично, но иногда и этого много.

debi12345 писал(а): то он может тупо нажать "резет"

тогда уж с розетки дернуть.

Воспользовался советом runewalsh:

Ты флушнул записанное перед этим?

Получился вот такой код:

Код: Выделить всё

procedure TForm1.EraseFileDisk(Path: String);
var
  bf: THandle;
  n: Longint;
  z: DWORD;
  M: array[1..256] of Byte;
begin
  for z:=1 to 256 do M[z]:=0;
  n:=FileSize(UTF8ToWinCP(Path));
  try
    bf:=CreateFile(PChar(Path),GENERIC_READ or GENERIC_WRITE, 0, Nil, OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
    SetFilePointer(bf,0,nil,FILE_BEGIN);
    while n>1 do begin
      if n>255 then z:=256
      else z:=n;
      WriteFile(bf,M,z,z,nil);
      FlushFileBuffers(bf);
      n:=n-z;
    end;
  finally
    CloseHandle(bf);
  end;
end;

После этой процедуры сразу идёт удаление.

Код: Выделить всё

DeleteFileUTF8(PChar(Path));

В результате перед удалением файла все данные на физическом диске затираются нулями, что, в принципе, и требовалось.
Тему можно закрывать.

Как решили проблему резета-выключения питания во время работы проги, не дающих проге затереть+удалить файл ?

А можно узнать о задаче более детально? Файл создается только во время работы программы, и требуется не оставлять следов? Так может лучше вообще в памяти все держать? Или файл слишком большой?

Добавлено спустя 22 минуты 51 секунду:
PS. Уже прочитал базовую тему.

Как решили проблему резета-выключения питания

Момент передачи данных в центральный оффис, после чего данные уничтожаются, определить сложно. Если, допустим, сеанс связи не состоялся, то состоится позже. Чисто теоретически, если всё-таки кому-то удастся предотвратить таким образом стирание, то суточная сводка или даже статистика одной точки особой ценности не представляет. Смотрите предыдущую тему.

Момент передачи данных в центральный оффис, после чего данные уничтожаются, определить сложно

Кому (по какой-то причине) надо будет прочесывать диск посекторно в поисках хвостов файла, тот уж о "моменте" точно сумеет позаботиться. В 1-ю очередь на время заменит свич на хаб и поставит у себя сниффер вроде WireShark - который умеет выуживать траффик в promiscious-режиме (не только свои пакеты, но и бегающие по всей локалке)

Чисто теоретически, если всё-таки кому-то удастся предотвратить таким образом стирание, то суточная сводка или даже статистика одной точки особой ценности не представляет

Хм, это обессмысливает всю тему - мы-то подумали, что вопрос секьюрити стоИт реально серьезно. Такие вопросы желательно решать на все 100%, иначе вообще не решать