How to remove a file so that it becomes almost non-recoverable.

If you’ve ever used the infamous rm command to remove something on Unix or Unix-like systems, then let me tell you something that will take you by a hurricane, the ‘rm’ command never exactly erases the entire file. That file is still in the system and is totally recoverable with the right techniques.

Read on to know what you can do to completely remove a file and also make it non-recoverable.

There’s a command that goes by the name, shred which helps us to wipe out disks and clear files in a secure fashion.

What actually is the Linux command shred and how is it different from rm?

Okay, so simply using the rm command doesn’t actually remove the file, it just removes the pointer that was pointing to that file. The actual data might still be there. Surprised? let’s head over to the Wiki reference of the command rm.

The rm command removes references to objects from the filesystem using the unlink system call. The command generally does not destroy file data, since its purpose is really merely to unlink references, and the filesystem space freed may still contain leftover data from the removed file. This can be a security concern in some cases…

But when you use the shred command, the file is overwritten a specified number of times in a way that the actual content is unrecoverable. Which makes the data nearly non-recoverable.

Let’s see an example of shred command in action,

I’ve got a colors.txt file on my system, let’s see what it has using the command cat colors.txt

checking the contents of our test file

Let’s also head over to the man page of shred command, before using it.

manual page of shred command

so we can use shred with option/s and then file/s to be shredded.

let’s peek more into the options:

options slate on the manual page of command shred

now it’s time to use the command shred with our colors.txt file,

shred -v colors.txt, -v is for the option of viewing the process of shredding.

shredding colors.txt

Great, works like wonder. Here you can see 3 passes in action, it means that the file colors.txt was overwritten 3 times. How can I be so sure of the overwriting? Let’s just display the file back and see for yourself:

using cat colors.txt

displaying the content of colors.txt after shredding

You can see that the file has been overwritten into some gibberish by the shred command.

After this we can simply remove this file, using the rm command. Or to make shred more effective we can simply use it with its inbuilt option -u, which de-allocates and removes the files after overwriting it.

Using the command, shred -vu colors.txt

-v : to show progress, and -u : to remove it totally.

overwriting and removing in action

shredding and removing

Here you can observe three things in action, : 3 passes to overwrite the file with random stuff, then renaming the file name to 0 and then ultimately removing it.

Let’s now jump into the more useful part of shred command, that is to securely erase a storage device, shred will overwrite the entire data in that file, making it nearly impossible to recover. Check it out on Ask Ubuntu

Concluding this all

shred makes sure the data is overwritten and is nearly impossible to recover. If safety is the foremost concern then shred is a wonderful option against widely used rm. But shred is little slow as compared to rm. I remember shredding my disk of size almost 4 gigs and it took me 20mins in doing so. Yeah, shred is little slow, uhh, let’s just stick to ‘slow’ for now.

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

Hey, if you were amused by this article do give me a follow. I love the command line and I call myself an artist whose art is programming.