删除文件（包括内容清理）
在我的应用程序中，我需要删除包含敏感信息的文件。为此，我正在写入文件由随机字节生成的一些垃圾，然后使用 File.delete() 方法删除，如下所示：
long size=file.length();
Random r=new SecureRandom();
OutputStream os=new BufferedOutputStream(new FileOutputStream(file));
while(size > 0)
{
os.write(r.nextInt());
size--;
}
os.close();
file.delete();
所以问题是：此方法是否保证如果有人取消删除文件，只会找到垃圾而不是垃圾真实内容？我不完全确定写入文件会保证下划线 Linux 文件系统中的相同扇区将被覆盖...请给出提示 - 该怎么做 - 以确保文件内容被破坏。
In my application I need to delete file with sensitive information. For that I'm writing to file some garbage generated by random bytes and then deleting using File.delete() method, like here:
long size=file.length();
Random r=new SecureRandom();
OutputStream os=new BufferedOutputStream(new FileOutputStream(file));
while(size > 0)
{
os.write(r.nextInt());
size--;
}
os.close();
file.delete();
So the question is: does this method guarantee that if someone will undelete file one will find only garbage instead of real content? I'm not completely sure that writing to file would guarantee that the same sectors in underline Linux filesystem will be overwritten... Please give a hint - what to do - to be sure that file content is destroyed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，它不能保证这一点。原因在于底层的文件系统实现 - 任何标准都不会强制它覆盖现有数据。实现文件系统写入操作的一种完全有效、符合（POSIX-）标准的方法是分配一个全新的存储块，将“新”数据放入其中，然后更改文件的块结构，如下所示：一种方式，新数据块被引用为您在文件中写入的位置，并且先前使用的数据块被“释放”——无论具体意味着什么。之后，您将无法再访问旧数据（通过文件系统），但它仍然在磁盘上，因此保存擦除整个存储介质并不会擦除痕迹。
许多文件系统的功能（例如快照或复制）实现都依赖于这种机制（写入时复制）。 Linux Btrfs 或 Solaris ZFS 广泛使用它。我想Android的YAFFS也是如此。正如 Chris 提到的，任何闪存中的磨损均衡 FTL 也会有类似的行为。
通常给出的如何在使用写时复制的文件系统上处理此问题的答案是，从一开始就永远不要让它发生。即在写入文件时对文件进行加密，在删除文件时“扔掉密钥”。你无法解密的东西就无法恢复......但我同意存在先有鸡还是先有蛋的问题，即在哪里/如何存储加密密钥。
No, it doesn't guarantee that. The reason for that is the filesystem implementation underneath - it is not forced by any standards to ever overwrite existing data. A fully valid, (POSIX-)standard-conforming way of implementing a write operation for a filesystem is to allocate a brand new block of storage, put your "new" data into there, and then change the block structure of the file in such a way that the new data block is referenced for the location you write in the file and the previously-used data block is "released" - whatever that means in detail. After that, you can't access the old data anymore (through the filesystem) but it's still on disk, so save erasing the entire storage medium you're not erasing the traces.
Many filesystem implementations of functionality like snapshots or replication rely on this mechanism (Copy-On-Write). Linux Btrfs or Solaris ZFS use it extensively. I think Android's YAFFS does too. As Chris mentioned, the wear leveling FTL in any flash memory will behave like that as well.
The answer that's usually given how to deal with this problem on filesytems employing copy-on-write is to never have it occur in the first place. I.e. encrypt the file when writing it, and "throw away the key" when deleting the file. What you can't decrypt you can't recover ... but I agree there's the chicken-egg problem of where/how to store the encryption key.
不，它不能保证原始块被覆盖 - 在闪存设备上，它们极不可能被覆盖，尽管人们可能需要低于操作系统级别甚至低于芯片数据表接口级别的工具来进行恢复。
你确实无法保证擦除，除非你的闪存没有板载控制器，可以替换块并从其低级驱动程序重复擦除和覆盖它，或者你物理地破坏介质。
如果您谈论的是具有胖文件系统的 SD 卡，我相信根据过去意外保存的后台图片编辑的恢复，Linux 甚至不会尝试写回文件系统的相同块。
您可以通过将卡放入 Linux 盒子中并在原始设备文件中查找已知已删除文件中的内容来确认数据仍然可以恢复；不幸的是，这并不能证明数据可能不在由设备驱动程序或片上控制器重新映射的块中，并且可以由较低级别的工具访问。
No, it does not guarantee that the original blocks are overwritten - on a flash device it's extremely unlikely that they would be, though one might need tools below the O/S level or even below the chip data sheet interface level to do the recovery.
You really cannot guarantee erasure except if you have flash memory with no on-board controller that can substitute blocks and repeatedly erase and overwrite it from its low level driver, or you physically destroy the media.
If you are talking about the SDcard with a fat filesystem, I believe based on past recovery of an accidentally saved back picture edit that linux doesn't even try to write back to the same blocks of the file system.
You can confirm that the data is still recoverable by putting the card in a linux box and grepping the raw device file for something known to be in the deleted file; unfortunately this will not prove that the data might not still be there in a block that's been re-mapped by the device driver or an on-chip controller, and potential accessible by a lower-level tool.