Comments on: Howto Delete Files Permanently and Securely in Linux

By: Jonathan DePrizio

Jonathan DePrizio — Mon, 05 Sep 2011 18:55:29 +0000

Test comment

By: sdmem not smem

sdmem not smem — Sat, 20 Aug 2011 18:14:02 +0000

It’s sdmem (not smem).

By: vijay

vijay — Wed, 10 Aug 2011 05:37:57 +0000

How to delete the any data form the server permantly. Any command for this in the linux.

By: vijay

vijay — Wed, 10 Aug 2011 05:36:07 +0000

Thanks for this tutorial!!!!!!!!!!

By: Daniel Feenberg

Daniel Feenberg — Fri, 05 Aug 2011 13:59:45 +0000

The necessity for multiple overwrites is subject to dispute. See my essay “Can Intelligence Agencies Recover Overwritten Data?” at

http://www.nber.org/sys-admin/overwritten-data-gutmann.html

By: Jonathan DePrizio

Jonathan DePrizio — Sat, 30 Jul 2011 14:52:37 +0000

Hi,

The reason why the tools are slow are that they need to access the hard disk in order to be effective. Under normal use, the OS will cache data in RAM for quicker access (and to make it appear that disk writes are faster than they actually are). Yet this wouldn’t work for secure deletion – you need to be certain that you actually writing to the disk.

So the answer is that no – you cannot really speed them up, except using one pass rather than multiple passes, etc… These tools need to bypass the system cache in order to be effective, thus making them slower than what you are generally used to.

By: JFekete9076

JFekete9076 — Sat, 30 Jul 2011 12:05:09 +0000

Hello.

I’ve also tried these programs.
The only problem is that they are too slow.
Is there a way to speed up them without compromising security?

By: securely delete (wipe) a file/partition « The Ubuntu Incident

securely delete (wipe) a file/partition « The Ubuntu Incident — Fri, 01 Jul 2011 06:03:40 +0000

[...] secure-delete tools (sudo apt-get install secure-delete); more info here [...]

By: olsie

olsie — Thu, 09 Jun 2011 20:30:05 +0000

This is well written and easy to apply. I no longer have to wear my tin foil hat 24/7…

By: name

name — Wed, 16 Feb 2011 12:48:51 +0000

it is sdmem not smem