Python 3.6 中的文件清理器:可能吗?

File Scrubber in Python 3.6: Is it possible?

文件在 "Deleted" 或 "Permanently Deleted." 之后确实保留在磁盘上 有些人可能不希望文件保留。为此,我写了这个:

#!/usr/bin/python3
from os.path import isfile, getsize
from os import remove
from secrets import randbits
from math import floor

filename: str
while True :
    filename = input('File: ')
    if filename.lower().strip() in ('', 'none', 'quit') :
        exit()
    elif isfile(filename.strip()) :
        filename = filename.strip()
        print()
        break
    else :
        print('\a')

iterations: int
while True :
    try :
        iterations = int(input('Number of iterations: ').strip())
        assert iterations > 0
        break
    except :
        print('\a')

file_size: int
try :
    file_size = getsize(filename)
except :
    print('No access.')
    exit()

for x in range(iterations) :
    y = floor(x / iterations * 100)
    print(f"{y:>02}%\r", end='')
    try :
        file = open(filename, 'wb+')
        file.write(bytes(randbits(8) for _ in range(file_size)))
    except :
        print('Access interrupted on {}%.'.format(y) if x else 'No access.')
        exit()
    finally :
        try :
            file.close()
        except NameError :
            pass

try :
    file = open(filename, 'rb')
    read = file.readall()
    file.close()
    #
    file = open(filename, 'wb+')
    file.write(bytes(randbits(8) ^ read[x] for x in range(file_size)))
    file.close()
    #
    remove(filename)
except :
    print('No access.')
    exit()
finally :
    try :
        if not file.closed : file.close()
    except :
        pass

print('Done.')

小心,这可能是魔法。我在写入二进制模式下使用直接磁盘访问,首先用加密随机字节覆盖磁盘上的文件若干次,然后用另一份随机字节对生成的文件进行异或,最后我删除了文件。

我的问题是:"wb+"是否直接覆盖为文件分配的物理磁盘的物理位置中的内容?

When working with a file object, does the "wb+" mode write directly over the contents in the physical location of the physical disk allocated for a file?

在 POSIX 中,不保证它适用于任意文件系统。不过,它可能适用于具有某些固定安装选项的某些固定实现。

参见示例 shred(7):

CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file system modes:

  • log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

  • file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems

  • file systems that make snapshots, such as Network Appliance's NFS server

  • file systems that cache in temporary locations, such as NFS version 3 clients

  • compressed file systems

In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount).

你也可以看看shred.c

Does the "wb+" write directly over the contents in the physical location of the physical disk allocated for a file?

不,在多个层面上。

目前使用的几乎所有操作系统都有磁盘读写的缓存机制来提高速度。因此,数据实际发送到磁盘可能需要一段时间。 在某些操作系统上 including ms-windows 您可以禁用写入缓存,但 写入性能会受到很大影响

此外,大多数现代硬盘驱动器也有 built-in 缓存。这由设备的固件控制并且对 OS 不可见。因此,即使是来自 OS 的命令告诉驱动器写入一些内容 returns,这也不能保证写入实际上已经完成。

还应该有相关文件的 备份 某处。您还必须找到并擦除它们。


顺便说一句,在现代硬盘驱动器上,用零覆盖一次文件可能就足够了。请参阅 data remanence 上的维基百科文章。