在我正在进行的项目中，我想让用户选择“安全地”删除文件 - 例如，用随机位或0覆盖它。在C＃.NET中有一种简单易行的方法吗？它的效果如何？
答案 0 :(得分：5)
您可以调用sysinternals SDelete为您执行此操作。这使用碎片整理API来处理所有棘手的边缘情况。
使用碎片整理API，SDelete 可以准确地确定哪些集群 在磁盘上被数据占用 属于压缩，稀疏和 加密文件。
如果您想以更方便的形式重新打包该逻辑，则会描述API here。
答案 1 :(得分：2)
您无法安全删除日记文件系统上的文件。唯一仍在大量使用的非日记系统是fat32。在任何其他系统上，安全删除的唯一方法是粉碎整个硬盘。
修改
安全删除不起作用的原因是，用于覆盖文件的数据可能不会与覆盖的数据存储在同一位置。
似乎微软确实提供了一个安全的删除工具，但它似乎并不能作为替代品使用。
防止删除文件恢复的唯一好办法是在将文件写入磁盘之前对文件进行加密，而不是粉碎磁盘。
答案 2 :(得分：1)
根本不安全。相反，您可能希望查看加密等替代解决方案。
一种解决方案是加密数据文件的内容。每次更新文件时都会使用新密钥。当您想要“安全地删除”数据时，只需“丢失”加密密钥并删除该文件。该文件仍然在物理磁盘上，但没有加密密钥恢复是不可能的。
以下是关于为什么“安全”覆盖文件的安全性较差的更详细说明：
如果没有低级别工具（在.net运行时之外），则无法访问物理磁盘位置。在NTFS上获取文件流，当您“打开文件进行写访问”时，您无法保证“更新”副本（在本例中为随机101010版本）将存储在同一位置（从而覆盖原始文件）。事实上，大部分时间都是这样：
1）文件x.dat从集群8493489开始存储 2）打开文件x.dat进行写访问。操作系统返回给您的仅仅是指向不仅仅是操作系统而是基础文件系统和设备驱动程序（例如硬件RAID）以及有时物理磁盘本身（SSD）抽象的文件流的指针。您可以使用随机1＆amp;更新文件的内容。 0并关闭文件流。
3）操作系统可能（可能会）将新文件写入另一个集群（比如集群4384939）。然后它将仅更新MFT，指示文件x现在存储在4384939。
对于最终用户来说，它看起来只有该文件的一个副本，并且它现在有随机数据，但原始数据仍然存在于磁盘上。
相反，您应该考虑在每次保存文件时使用不同的密钥加密文件的内容。当用户想要文件“删除”时删除密钥和文件。物理文件可能仍然存在但没有加密密钥恢复是不可能的。
答案 3 :(得分：0)
答案 4 :(得分：-1)
我首先尝试打开文件并像往常一样覆盖其内容。在C＃中相当微不足道，我甚至都懒得写它。但是我不知道那会有多安全。首先，我很确定它不适用于使用复杂算法提供磨损均衡的闪存驱动器和SSD。我不知道那里有什么用，也许它需要在驱动程序级别完成，也许根本不可能。在普通的驱动器上，我只是不知道Windows会做什么。也许它会保留旧数据。