As UNIX SysAdmin, I don't think this makes any sense at all.

First, filling up your drive is a very bad idea, as Rob points out. Many services will stop functioning or exhibit odd behavior.

Secondly, I'm not quite sure what you're trying to do here? Make sure any unused sectors are zero'd out? I'm guessing you're using secure delete already anyways. This just doesn't make any sense. Do you work for the NSA? Didn't think so. You don't need to 'zero' your unused disk space.


P.S. - This '35 pass delete' stuff is B.S. The only way to recover data from a HD after 3 passes is with a team of people and highly specialized hardware. Sorry everybody, but my guess is that your data is not that important. Save your hard drive life and stop using 35-pass deletes. If you have sensitive data, encrypt it using a strong passphrase and you'll be much better off.


---
Nem W. Schlecht
http://geekmuse.net/

[ Reply to This | # ]

Not only is this not a good idea, it doesn't entirely work as advertised. Realize that changes to files are often not written to disk immediately. Instead, they are held in memory (cached) and queued for writing to disk. So, when your cat command dies due to insufficient space, it's likely that some of the writes have not completed. When the file is removed, those writes can be deleted from the queue of pending writes. Consequently, some of the disk blocks will never be overwritten.

Also, many filesystems limit the amount of disk that a regular user (i.e. not root) can write to. For instance, UFS reserves 10% of a filesystem (by default, can be set with tunefs minfree option) for root. This would mean that the above command would fail after writing to 90% of the disk, not 100% (leaving 10% unwritten). Unfortunately, I'm not familiar with the implementation of HFS+, so I can't comment on whether it has similar behavior.

[ Reply to This | # ]

"Do you work for the NSA? Didn't think so. You don't need to 'zero' your unused disk space."

I'm guessing you know the things I'm about to say already and just didn't think about them when you wrote this, but using secure erase means that Finder is configured to do secure erase when it empties the trash. It has no impact on, say Quicken's temporary files in /tmp . File in /tmp are also outside of the user's FileVault (assuming this person is using FileVault). There have also been multiple cases where people have suffered identity theft after their financial information was lifted from old drives despite the fact that it had already been (insecurely) deleted on the old drive.

With that said, FileVault, secure erase, and encrypted VM will cover the vast majority of people's needs. In fact, simple lack of familiarity with HFS+ on the part of thieves will cover a lot. Nonetheless, there are legitimate cases for a non-FBI-employee to want to erase the blank space on a root drive.

[ Reply to This | # ]

some of us do. given, this isn't the best way to go about it, it would help prevent some data recovery.

if you want to use this method, i would recommend booting into single use mode first. (cmd-opt-s)

diskutil is the correct way to do this.

------
Disk Utility Tool
Usage: diskutil secureErase [freespace] level
MountPoint|DiskIdentifier|DeviceNode
Securely erases a disk or its freespace.
Level should be one of the following:
1 - Single-pass randomly erase the disk.
2 - US DoD 7-pass secure erase.
3 - Gutmann algorithm 35-pass secure erase.
Ownership of the affected disk is required.
Example: diskutil secureErase 2 /dev/disk2
Note: Level 2 or level 3 secure erases can take an extremely long time.


[ Reply to This | # ]