Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A faster way to securely delete files System
I recently found myself wanting to securely delete a non-encrypted copy of my home directory. No big deal, I thought: I moved the copy to the trash and chose Finder » Secure Empty Trash. After that, I left my MacBook running and returned after a while ... only to find 96,000 files still left. I watched the progress for a bit, and counted roughly one file per second. I did the math and found ... too long!

So I chose the following route: I deleted the file in the Finder, emptied the trash the usual way, and then erased empty disk space with Disk Utility. This did the trick in half an hour.

I chose the fastest method in Disk Utility, i. e. overwriting only once. But frankly, except for the most paranoid this should be safe enough. (Wright, Kleiman and Sundhar have thoroughly debunked the myth about having to overwrite files several times).

It might not even be that the Finder is really inefficient in what it does, but that its default is possibly overwriting seven or 35 times. So changing that default (hidden prefs, anyone?) could then actually make the Finder faster for that purpose than Disk Utility.
  • Currently 2.33 / 5
  You rated: 5 / 5 (12 votes cast)

A faster way to securely delete files | 13 comments | Create New Account
Click here to return to the 'A faster way to securely delete files' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A faster way to securely delete files
Authored by: victory on Feb 05, '09 10:17:47AM
Nice tip!

To do this from the cmd-line instead, use:

diskutil secureErase freespace 1|2|3 [device]

1 = Single pass randomly erase the disk.
2 = US DoD 7 pass secure erase.
3 = Gutmann algorithm 35 pass secure erase.

Use df, mount, etc. to determine the device specifier for the volume.
** DO NOT FORGET THE 'freespace' KEYWORD! **

In the past, I've used a slightly safer (but less secure) method:

dd bs=1024 if=/dev/zero of=dummy-file; sync;rm -f dummy-file

The idea is simply to create a huge dummy file filled with zeros (you could also use /dev/random) that grows to use up all your remaining space on a volume. Once it does, dd will quit and the dummy file is deleted immediately afterwards. Note that this method isn't 100% secure because it doesn't take into account all the underlying disk caching mechanisms and it's probably not ideal for running on your root OSX volume which expects to have a certain amount of minimum free space all the time.

On another note, I believe the Finder uses /usr/bin/srm under the hood for its secure-delete option. As you mentioned, it appears from the srm manpage that a multi-pass method is used by default:

"The -s option overrides the -m option, if both are present. If neither is specified, the 35-pass Gutmann algorithm is used."

One final reminder: Once files are deleted, I don't know if Spotlight securely overwrites its underlying database files used for metadata storage. In other words, unless Spotlight was specifically disabled for a volume, it's possible that some file metadata may survive in the internal Spotlight database, even using the techniques described in these hints.

[ Reply to This | # ]
Or use srm
Authored by: googoo on Feb 05, '09 10:29:04AM
Another way to securely delete files from the command line is to use the srm command. If you want to delete a all subdirectories with a one-pass overwrite, use the command

% srm -rs path/to/top/directory/to/delete

See the srm man page for more details.


[ Reply to This | # ]
thoroughly debunked the myth ?
Authored by: Osc on Feb 05, '09 03:19:17PM
from :
[Further Epilogue]
"A recent article claims to be unable to recover any overwritten data using an MFM to perform an error-cancelling read. This isn't surprising, since the article confuses two totally unrelated techniques. One is the use of an MFM to recover offtrack data, discussed in paragraph 7 of section 2 and illustrated in one of the slides from the 1996 talk (and in several of the papers cited in the references). The other is the use of an error-cancelling read (in this case using a high-speed sampling scope) to recover overwritten data, discussed in paragraph 6 of section 2. Unfortunately the authors of the article confused the two, apparently attempting to perform the error-cancelling read using an MFM(!!) (I'm currently on holiday but will try and contact them when I get back to verify this... I wish they'd asked me before they put in all this effort because I could have told them before they started that this mixture almost certainly wouldn't work). Given that these are totally different techniques exploiting completely unrelated phenomena, it's not surprising that trying to use one to do the other didn't work."

Same page, further up:
"In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. 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."

That said, I use what googoo/Mark suggests: srm =]

[ Reply to This | # ]
thoroughly debunked the myth ?
Authored by: bdm on Feb 06, '09 10:53:08PM

I don't get your point. The article you link to is more than 10 years earlier that the one claiming to debunk it.

[ Reply to This | # ]
thoroughly debunked the myth ?
Authored by: ghay on Feb 08, '09 06:55:42AM

That's because you haven't taken the time to read either.

The article "debunking" multiple overwrites, is completely flawed - as it says in the posters text. They use incompatible methods of reading and writing.

For the more hard of reading, it would be like storing English data in German, but then using a Spanish->English translator to read it back - the result - you can't read it.

That isn't "debunking" it's bad science.

[ Reply to This | # ]
A faster way to securely delete files
Authored by: ikioi on Feb 05, '09 03:37:25PM

According to this page, in Mac OS X 10.4 the command that Finder uses to securely delete files was hard coded in the file.


One of the comments on that page explains that in 10.5 is got moved to a preference in . So, if you have Leopard, then you should be able to do something like:

defaults write _FXSecureEmptyTrashLevel 9

To get Finder's secure deleting to use only one pass of random data.

I haven't tried or verified these things myself though, so I can't swear they still work.

[ Reply to This | # ]
A faster way to securely delete files
Authored by: dani190 on Mar 08, '09 05:06:33PM

i tried it and it seemed to work, but according to a comment above i did this.

defaults write _FXSecureEmptyTrashLevel 7

then killed finder, and it worked perfect.

[ Reply to This | # ]
A faster way to securely delete files
Authored by: mantrid on Mar 08, '09 06:27:53PM

The only safe values mentioned are "9" and "-1".

I would proceed under the assumption that anything else deletes insecurely unless you test it first hand and find otherwise.

[ Reply to This | # ]
A faster way to securely delete files
Authored by: zo219 on Feb 06, '09 12:31:09AM

I've mentioned MainMenu before ... It securely empties trash (on all volumes) so fast, I no longer burden poor Finder with a similar job of any size. Try it, am just amazed.

[ Reply to This | # ]
A faster way to securely delete files
Authored by: System7 on Feb 06, '09 07:46:44AM
I'd be interested to hear more about why overwriting doesn't actually work. I saw a BBC Horizon program on forensics once, where they partially restored an IRA hard drive which had been erased with triple DES and Blowfish, sufficient to secure a conviction beyond a reasonable doubt.

Also, this is something which you may be already aware of, but the "Read More..." link in your RSS feed doesn't point to the actual article (see screen shot).

[ Reply to This | # ]
A faster way to securely delete files
Authored by: Felix on Feb 06, '09 03:48:13PM

And I thought the government agency I work for is just being overly cautious by requiring physical destruction of drives with some classes of information stored thereon.

Maybe not!

[ Reply to This | # ]
A faster way to securely delete files
Authored by: pcunix on Feb 06, '09 05:55:31PM

I can't find the article right now, but if I remember correctly it has to do with the slightly wobbly nature of the magnetic spots - the head movements aren't precise so they overlap - meaning some of the original is off to the left or the right.. and that can be picked up with specialized equipment.

Tony Lawrence
Free SCO, Mac OS X and Linux Skills Tests:

[ Reply to This | # ]
A faster way to securely delete files
Authored by: dandj on Feb 06, '09 07:27:28PM

In the defence business, to declassified or remove classified data on a hard drive requires the physical destruction of the drive with a hammer (or similar) and witnessed by a security officer. Overwriting is not sufficient to meet security procedures.

That pretty secure deletion, and quicker than the Finder.

Same applies to toner cartridges from copiers and printers used for classified work.

[ Reply to This | # ]