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

An AppleScript to securely erase files System
Along the lines of the hint on AppleScript and Calendar, I offer a probably not perfect additional example of integrating AppleScript with command line tools. It also demonstrates how to create a simple "droplet" script that you can drop one or more files or folders on. In this case it is a script I've dubbed Secure Erase that securely deletes anything dropped on it, with appropriate warning.

Needless to say, you should use this script with caution! It is mainly intended as an example, albeit a potentially useful one. Download either the script application or the text version or both. Note that you can drag the script application onto Script Editor to edit it, so the text version isn't strictly necessary.

The dirty work is handled with the command-line command "rm -rP" and AppleScripts's "do shell script" and "POSIX path" from the "Standard Additions" scripting addition are what do that.

You are free to use this script in any way you see fit as long as nothing in it is used in a for-profit endeavor. No warranties are expressed or implied - i.e. any damage caused by it is your own damn fault! Please DO suggest improvements.
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)

An AppleScript to securely erase files | 7 comments | Create New Account
Click here to return to the 'An AppleScript to securely erase files' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Secure Deletion
Authored by: Cadre on Apr 11, '02 03:25:06PM

It should be noted that the -P flag only works on fixed-block filesystems, which I believe HFS+ is not. If you use UFS, it should work as advertised though.

[ Reply to This | # ]
Secure Deletion
Authored by: imacusr on Apr 11, '02 04:07:53PM
Do you happen to know if shred would work properly on HFS+?

[ Reply to This | # ]
Works fine on HFS+ (or not??)
Authored by: sjonke on Apr 11, '02 05:46:49PM

Or at least it seems to work fine on my PowerBook and it has an HFS+ formatting. What would be the behavior of it NOT working? Would it still delete, but not do so securely? If that is the case, then I'll pull this, because that would be a very bad thing, to think something was securely deleted when it was not.


[ Reply to This | # ]
Looks like HFS+ is fixed-block size
Authored by: sjonke on Apr 11, '02 06:01:05PM
From reading Apple's developer page on HFS+, it looks to me like HFS+ is fixed-block, it's simply more efficient than HFS because there are more blocks available to spread over the whole disk (32-bits worth instead of 16):
HFS divides the total space on a volume into equal-sized pieces called allocation blocks. It uses 16-bit fields to identify a particular allocation block, so there must be less than 216 (65,536) allocation blocks on an HFS volume. The size of an allocation block is typically the smallest multiple of 512 such that there are less than 65,536 allocation blocks on the volume (i.e., the volume size divided by 65,535, rounded up to a multiple of 512). Any non-empty fork must occupy an integral number of allocation blocks. This means that the amount of space occupied by a fork is rounded up to a multiple of the allocation block size. As volumes (and therefore allocation blocks) get bigger, the amount of allocated but unused space increases. HFS Plus uses 32-bit values to identify allocation blocks. This allows up to 2 32 (4,294,967,296) allocation blocks on a volume. More allocation blocks means a smaller allocation block size, especially on volumes of 1 GB or larger, which in turn means less average wasted space (the fraction of an allocation block at the end of a fork, where the entire allocation block is not actually used). It also means you can have more files, since the available space can be more finely distributed among a larger number of files. This change is especially beneficial if the volume contains a large number of small files.
However, that's just my reading of it. I don't claim to be an expert. They don't explicitly use the phrase, "fixed-block" anywhere that I can find. Anyone know for certain?

[ Reply to This | # ]
Looks like HFS+ is fixed-block size
Authored by: jlowrey on Apr 12, '02 01:50:41AM

I wrote Trash X. When I added file shredding features to it, I relied on "rm -P" to handle the task. This was an embarassing mistake. In short, "rm -P" does not reliably shred files on HFS+ volumes. In my tests, it only worked on HFS+ in situations where the file to be shredded was larger than the available free space. In all other cases with HFS+, "rm -P" merely deleted the file without overwriting it. It is interesting to note however that "rm -P" takes longer to execute than just "rm". I believe that on HFS+ disks, "rm -P" essentially deletes the old file and creates a new file on each pass and writes its data sequence into it, but that is just conjecture on my part.

It upsets me to see "rm -P" so frequently touted as a CLI file shredding option. The reality is that most OS X users are using HFS+ partitions, and that is what Apple ships out of the box. For the majority of OS X users, "rm -P" is not a viable option.

And now the shameless plug. To my knowlege, Trash X is the only OS X GUI file shredder that offers support for files larger than 2 GB, and supports shredding freespace on disks.



[ Reply to This | # ]
full path!
Authored by: mervTormel on Apr 12, '02 01:54:06AM

it should be noted that scripts need to make very sure they are using the full pathname to the intended command.

all references to rm should be to /bin/rm

if you had a custom rm command found in your path before /bin/rm, results would be dubious, if not disastrous. right?

[ Reply to This | # ]
Authored by: calroth on Apr 21, '02 08:38:10AM

How about just repeatedly overwriting the file with /dev/random, like Neal Stephenson describes in Cryptonomicon? (Whoa, he's getting his security ideas from popular fiction.)

[ Reply to This | # ]