Надежное удаление файла в C # .NET

Question

В проекте, который я делаю, я хочу дать пользователям возможность «безопасного» удаления файла - например, перезаписывая его случайными битами или нулями. Есть ли простой способ сделать это в C # .NET? И насколько это будет эффективно?

Answer 1

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

Использование API дефрагментации, SDelete может точно определить, какие кластеры на диске заняты данными принадлежность к сжатым, разреженным и зашифрованные файлы.

Если вы хотите упаковать эту логику в более удобную форму, API описан здесь .

Answer 2

Вы не можете безопасно удалить файл в файловой системе журналирования. Единственная система без журналирования, которая все еще активно используется - это fat32. В любой другой системе единственный способ безопасного удаления - уничтожить весь жесткий диск.

EDIT

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

Кажется, что Microsoft действительно предоставляет безопасный инструмент удаления, но это не то, что вы можете использовать в качестве капли замены.

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

Answer 3

Это не будет безопасно вообще. Вместо этого вы можете рассмотреть альтернативные решения, такие как шифрование.

Одним из решений будет шифрование содержимого файла данных. Новый ключ будет использоваться каждый раз, когда файл обновляется. Если вы хотите «безопасно удалить» данные, просто «потеряйте» ключ шифрования и удалите файл. Файл все еще будет на диске физически, но без ключа шифрования восстановление было бы невозможно.

Вот более подробное объяснение того, почему «безопасная» перезапись файлов является плохой безопасностью:

Без инструмента низкого уровня (вне среды выполнения .net) у вас нет доступа к расположению физического диска. Возьмите файловый поток в NTFS, когда вы «открываете файл для доступа к записи», у вас нет гарантии, что «обновленная» копия (в данном случае случайная версия 101010) будет храниться в том же месте (перезаписывая оригинальный файл). Фактически, в большинстве случаев именно так и происходит:

1) Файл x.dat хранится начиная с кластера 8493489 2) Вы открываете файл x.dat для доступа на запись. ОС возвращает вам просто указатель на файловый поток, абстрагированный не только ОС, но и базовой файловой системой и драйверами устройств (например, аппаратный RAID), а иногда и самим физическим диском (SSD). Вы обновляете содержимое файла со случайными 1 и 0 и закрываете поток файлов.

3) ОС, вероятно, может (и, вероятно, будет) записывать новый файл в другой кластер (например, кластер 4384939). Затем он просто обновит MFT, указав, что файл x теперь хранится в 4384939.

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

Вместо этого вам следует рассмотреть возможность шифрования содержимого файла другим ключом при каждом сохранении файла. Когда пользователь хочет "удалить" файл, удалите ключ и файл. Физический файл может остаться, но без ключа шифрования восстановление будет невозможно.

Answer 4

Реализация стирания Гутмана

Answer 5

Сначала я бы попытался просто открыть файл и перезаписать его содержимое, как обычно. Довольно тривиально в C #, я даже не буду писать это. Однако я не знаю, насколько это будет безопасно. Во-первых, я совершенно уверен, что он не будет работать на флэш-накопителях и твердотельных накопителях, которые используют сложные алгоритмы для обеспечения выравнивания износа. Я не знаю, что будет работать там, возможно, это нужно будет сделать на уровне водителя, возможно, это будет вообще невозможно. На обычных дисках я просто не знаю, что будет делать Windows. Возможно, он также сохранит старые данные.