Securely overwrite the free space and inodes of the partition where the specified directory resides.


Overwrite free space and inodes of a disk with 38 writes (slow but secure)

$ sfill [/path/to/mounted_disk_directory]

Overwrite free space and inodes of a disk with 6 writes (fast but less secure) and show status
$ sfill -l -v [/path/to/mounted_disk_directory]

Overwrite free space and inodes of a disk with 1 write (very fast but insecure) and show status
$ sfill -ll -v [/path/to/mounted_disk_directory]

Overwrite only free space of a disk
$ sfill -I [/path/to/mounted_disk_directory]

Overwrite only free inodes of a disk
$ sfill -i [/path/to/mounted_disk_directory]


sfill [-f] [-i] [-I] [-l] [-l] [-v] [-z] directory/mountpoint


sfill is designed to delete data which lies on available diskspace on mediums in a secure manner which can not be recovered by thiefs, law enforcement or other threats. The wipe algorithm is based on the paper "Secure Deletion of Data from Magnetic and Solid-State Memory" presented at the 6th Usenix Security Symposium by Peter Gutmann, one of the leading civilian cryptographers.

The secure data deletion process of sfill goes like this:


1 pass with 0xff


5 random passes. /dev/urandom is used for a secure RNG if available.


27 passes with special values defined by Peter Gutmann.


5 random passes. /dev/urandom is used for a secure RNG if available.

afterwards as many temporary files as possible are generated to wipe the free inode space. After no more temporary files can be created, they are removed and sfill is finnished.



fast (and insecure mode): no /dev/urandom, no synchronize mode.


wipe only free inode space, not free disk space


wipe only free disk space, not free inode space


lessens the security. Only two passes are written: one mode with 0xff and a final mode with random values.


-l for a second time lessons the security even more: only one random pass is written.


verbose mode


wipes the last write with zeros instead of random data

directory/mountpoint this is the location of the file created in your filesystem. It should lie on the partition you want to write.



Most filesystems (ext2, ffs, etc.) have several features included to enhance performance, which will result in that sfill might not receive all available free space. Sad but true. Nothing can be done about that ...


Beware of NFS. You can't ensure you really completely wiped your data from the remote disks. (especially because of caching)


Raid Systems use stripped disks and have got large caches. It's hard to wipe them.


Some of your data might have a copy in your swapspace. sswap is available for this task.


No bugs. There was never a bug in the secure_deletion package (in contrast to my other tools, whew, good luck ;-) Send me any that you find. Patches are nice too :)


The newest version of the secure_deletion package can be obtained from

sfill and the secure_deletion package is (C) 1997-2003 by van Hauser / THC (

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.


srm(1), sswap(1), sdmem(1)


van Hauser / THC <>

Copied to clipboard