Bas*_*asj 3 python io file python-3.x
它可能取决于每个操作系统，并且还取决于硬件，但是Python中有一种方法可以要求对文件的写操作“就地”发生，即在原始文件的同一位置发生，即如果可能的话磁盘上的相同扇区？
例如：假设sensitivedata.raw必须加密4KB文件：
with open('sensitivedata.raw', 'r+') as f: # read write mode
s = f.read()
cipher = encryption_function(s) # same exact length as input s
f.seek(0)
f.write(cipher) # how to ask this write operation to overwrite the original bytes?
示例2：将文件替换为相同大小的空字节内容，以避免使用未删除的工具恢复该文件（当然，要正确执行此操作，我们需要多次传递，不仅随机数据而且还包含空字节，但这里只是一个想法）
with open('sensitivedata.raw', 'r+') as f:
s = f.read()
f.seek(0)
f.write(len(s) * '\x00') # totally inefficient but just to get the idea
os.remove('sensitivedata.raw')
PS：如果这确实取决于操作系统，那么我主要对Windows机箱感兴趣
侧quesion：如果它在SSD的情况下是不可能的，这是否意味着，如果你曾经在你的生活中写道敏感数据以明文形式在SSD（例如：明文密码，加密私钥，或其他任何东西，等），那么有没有办法确保该数据确实被擦除了？即唯一的解决方案是100％擦除磁盘并用随机字节填充很多遍？那是对的吗？
施加这是不可能的要求。尽管在大多数旋转磁盘驱动器上，这将自动发生（没有必要在可以直接覆盖现有数据的情况下将新数据写入其他位置），但是SSD 无法做到这一点（当他们声称这样做时，他们在撒谎到操作系统）。
SSD不能重写块。他们只能擦除一个块，或写入一个空块。“重写”的实现是写入一个新块（如果没有足够的新数据，则从原始块读取以填充该块），然后（最终，由于其相对昂贵）擦除旧块以使它可供将来编写。
更新解决附带的问题：唯一真正安全的解决方案是将驱动器穿过削木机，然后用磨石压碎残留物。:-)实际上，在大多数情况下，SSD上的漏洞窗口应该相对较短；擦除扇区的成本很高，因此即使是不满意的SSD也TRIM通常会在后台执行此操作，以确保将来（廉价）的写操作不会被（昂贵的）擦除操作所阻止。考虑一下，这并不是很糟糕。当然，在逻辑上删除数据之后的一段时间内，数据是可见的。但在一段时间之前可见您也删除了它，所以所有这些操作就是将漏洞的窗口延长了（秒，分钟，小时，天，具体取决于驱动器）；错误是首先将敏感数据存储到永久性存储中；即使采用了极端的解决方案（木匠+磨石），在您考虑加密/销毁数据之前，其他人也可能会偷偷摸摸地复制数据。