Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
I was reading the man page for rm when I came across this option:
-P Overwrite regular files before deleting them. Files are overwritten
three times, first with the byte pattern 0xff, then 0x00, and
then 0xff again, before they are deleted.
I guess -P is meant for thoroughly deleting a file, but wouldn't setting all the bytes to 0xff or 0x00 be enough? Why does it have to toggle between the two three times?
There is a technique called residual information retrieval that can read data that was deleted based on the idea that when the drive is magnetized in order to store data other parts that are close to the data is also affected by this and it should be possible to re-read data this way ... this is though a costly technique, but use it if you are paranoid ;)
By writing data 3 times (in this case) the parts next to the track on the drive should be re-set as well in order to make it impossible to re-read this way.
This option is largely useless. Overwriting with multiple patterns is a bit of paranoia that isn't justified by real-world tests: on modern hard disks, overwriting once or multiple times, with zeroes or ones or random patterns, doesn't make any difference. The case is less clear for SSD, but these have their own issues; overwriting multiple times wears out the device faster without really helping wipe out the data anyway.
The main reason wiping a file when deleting it is largely useless is that very often there are previous versions of the file, editor backups, editor swap files and so on that were not wiped. Furthermore, the filesystem itself may have modified data around (due to defragmentation or a filesystem check).
If you're afraid that a file may leave crumbs behind, encrypt it. If a file is encrypted, you don't need to take any precaution when deleting it; you only need to make sure not to leak the key. You can encrypt the file specifically, in which case you should make sure that all backups and other files that may contain all or part of the data are also encrypted; or you can encrypt the volume that the file is on (which usually takes care of these other files).
For more information, see
In that it scrubs the contents of the file before unlinking (to prevent recovery), it would also be scrubbing the "other copies" of the file (really the same file) that might exist elsewhere on the filesystem in the form of hard links.
With BTRFS or any other copy-on-write filesystem, I expect it would do nothing for forensic destruction of the data, though all the other hard links to the file would be composed of junk. It would also leave any other cow-copies of the file untouched... or any copies of the file in snapshots.
