Shred tries to really remove any trace of a file from a disk. It
seems like such an easy thing to do: even if you already understand
that "rm" merely disassociates data blocks from an inode and returns
them to the free list, why wouldn't just overwriting the file with
a bigger file destroy the data? Well, because disks are mechanical
devices and storage is quite fuzzy, so weak images of previous
data are still present after a simple overwrite. Also, disk heads may
move slightly out of track over time, leaving a magnetic trail
"off to the side". Those problems and more are
discussed in depth at Secure Deletion of Data from Magnetic and Solid-State Memory by
Most of us have no need for such forensic obstructing scrubbing. Good
thing that we don't, because the "info shred" page tells us that
"shred --verbose /dev/fd0" could take 20 minutes. It's a bit quicker
at running through a hard drive file but it still takes noticeable
Should you really need to do such a thing, be aware that there
are lots of things that can trip you up - ordinary disk caching
prevents "shred" from really doing what it intends. You can use
"chattr +S" on the file before running shred to get the writes
forced through the cache. Using "shred" is probably fine if you
are giving away a computer and don't want its next owner to see your data
(in which case you shred filesystems rather than files), but if
you have serious reasons to need data securely destroyed,
physical destruction of the media is the only real answer.
With Linux ext3, "shred" is a bit less necessary (from
Q: How can I recover (undelete) deleted files from my ext3 partition?
Actually, you can't! This is what one of the developers, Andreas
Dilger, said about it:
In order to ensure that ext3 can safely resume an unlink after a
crash, it actually zeros out the block pointers in the inode,
whereas ext2 just marks these blocks as unused in the block bitmaps
and marks the inode as "deleted" and leaves the block pointers
Your only hope is to "grep" for parts of your files that have been
deleted and hope for the best.
HOWTO recover deleted files on an ext3 file system disagrees:
However, this is utter nonsense. All information is still there, also the block pointers. It is just slightly less likely that those are still there (than on ext2), since they have to be recovered from the journal. On top of that, the meta data is less coherently related to the real data so that heuristic algorithms are needed to find things back.
On February 7th, 2008, I accidently deleted my whole home directory: over 3 GB of data, deleted with rm -rf. The only backup that I had was from June 2007. Not being able to undelete was unacceptable. So, I ignored what everyone tried to tell me and started to learn how an ext3 file system really works, and what exactly happens when files are deleted...
Three weeks and nearly 5000 lines of code later, I had recovered every file on my disk.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2012-07-17 Tony Lawrence