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?

3 Answers 3


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.

  • 5
    I found a good wiki article on the subject, too: en.wikipedia.org/wiki/Data_remanence. Thanks!
    – theabraham
    Commented Apr 19, 2012 at 14:49
  • 1
    “There is a technique” – no. There is a hypothesised technique that’s never been shown to work, and which many professional data retrieval companies have deemed infeasible. There are conspiracy theories that secret agencies do harness this technique but given that the technical details have been debunked, they are just that – conspiracy theories. Commented Jul 10, 2012 at 12:48

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .