Talk:Srm (Unix)

Latest comment: 12 years ago by DGerman in topic Looks like serious flaws in here

secure erase edit

I would like to include the information from [dr gordon hughes website|http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml] but I'm not sure what it's licensed under or which article to put it in.

Looks like serious flaws in here edit

  • It fails to address the filesystem issues of "where do I try to write data this time, and will it be in the same location that data was written in the past"
  • It fails to even understand the "35 pass" routine. You don't need, or want, 35 passes. You only want those passes -- about 2-5 -- that are relevant for your disk hardware. The ones that aren't relevant for your hardware are a waste.

<quote>For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, "A good scrubbing with random data will do about as well as can be expected". This was true in 1996, and is still true now.</quote>

  • The whole issue of file forks isn't properly addressed there. Most modern file systems have some form of "This file is a directory" (as opposed to the older "this directory is a file"). Whether it's "hidden directories" (so a directory with a name like "sparc" or "hpux" or "i386" is skipped in the lookup), or alternate data streams, or arbitrary forks associated with a file (not just data/resource), there's more to clean out than just the main stream.

Unless you know that you will be writing to the same place on the disk, it has no value. For that situation, you need the "erase free space" feature of disk util, or the equivalent.

The point is: Erasing data needs to be an operating system level operation. Not a user level operation. Unlinking and erasing are not the same. Erasing is going to be both a hardware-dependent function (different storage systems will do it differently) and a software level function (how you erase something on HFS won't the be the same as on reiser or log-structured.) Keybounce (talk) 01:17, 12 September 2010 (UTC)Reply

Inclusion of this screen shot seems unnecessary. DG12 (talk) —Preceding undated comment added 01:50, 8 November 2011 (UTC).Reply