Disk Utility: Free space overwrite fails; disk image fix?

The 'cat' and 'dd' suggestions are good. I would lean towards a 'dd' with a large 'bs=<a multiple of 4096>', such as:

dd if=/dev/zero of=$HOME/file.1.zero bs=262144
cat /dev/zero >$HOME/file.2.zero  # use up every last free block
rm $HOME/file.1.zero
rm $HOME/file.2.zero

If these operations are interrupted, then you will have zero'ed or randomized the number of bytes indicated by the size of the file. Nothing will be corrupted by interrupting, and you can delete the file to get your free space back.

Using a "disk image" means you are creating a file system inside a regular file. File systems arrange things internally to their liking and they may have sections that are unwritten even when you have used up all the free space. I would not use a "disk image" as a way to zero (randomize) free space. But with respect to interrupting the "disk image" while creating it or trying to fill it up, you do not care. It is just a regular file that has some fancy internal formatting. The outside real file system just sees it as a regular file, and you can just delete it, regardless of whether or not the insides are messed up. And yes, whatever has been written is zeroed (or randomized).

Closing comments:

• This is not really good for SSD's as they have a limited number of writes, and writing to every free block just insures you have reduced the life of the SSD
• SSDs also have a pool of replacement cells, which depending on the size of the SSD, could be a few gigabytes. They may not be erased.
• You should be using FileVault so that when you decide to discard the drive, it cannot be read by anyone that does not have the encryption key. Also if using an SSD, even blocks in the pool of replacement cells are encrypted over time. Any data you write is encrypted.

Guy Burns wrote:

…

Ques 1

Is this workaround effectively the same as Disk Utilities option to erase free space (an option that I've given up on), but leaving a small amount of data unzeroed?

Ques 2

If I cancel the process before it is finished, does that mean the data up to that point has been erased?

Questions: Close enough, and close enough, respectively.

Old HDDs do flake. I have some well past twenty-five years, and others tipped over just past the warranty.

I’d aim DriveDx at these, and see whether particular issues might await.

Similar lower-level zeroing can be:

cat /dev/zero > /path/to/volume/zero.dat

This file will take a while to create and to delete too, due to fragmentation, and inefficient zeroing.

Your overarching goal here is unclear, past the immediate free-space overwriting. Depending on that goal, encryption can be reasonable and appropriate.

Any machine still running Mavericks, is lucky to have a functioning hard drive to begin with. The half life of many hard drives is 7 years. Many of these failures can be due to media that is failing or connectivity to the media that is failing. Binaryfruit's DriveDX is one of the few packages that can actually give you a good read on how good or bad your drive is.

While you can do workaround 1, the general rule of thumb is keeping at least 15% of your drive free to avoid complications.

Canceling the process before it finishes can leave the formatting in a tenuous state, and may not be recoverable without a full reformat and wipe.

MrHoffman wrote:

Your overarching goal here is unclear, past the immediate free-space overwriting.

I should amend my earlier reply, for that reason.

Similar lower-level zeroing can be:

cat /dev/zero > /path/to/volume/zero.dat

Agreed, but if you were to do that, it is possible to create a file of < ∞ size that will nevertheless occupy a negligible amount of actual storage space. Get Info will (for example) indicate Size as many terabytes, and Finder may eventually indicate zero disk space remaining, when in fact there will be plenty of available storage space. It's one of APFS's many entertaining quirks.

This file will take a while to create and to delete too, ...

... since Unix is going to do what Unix does. Meanwhile, macOS's low level file system is just laughing because it sees through the futility of doing whatever it is you're attempting to do... since your overarching goal is unclear.

"Zeroing" a hard disk drive in the manner you propose has little if any practicable benefit. If it is your intent to obscure its prior contents, then what you really should be doing is to read from /dev/urandom for example.

So, perhaps you would be better served if you were to describe the reason for your proposed actions.

Edit: I intended to reply to the OP in case that's not patently obvious.

anotherEdit: Mavericks predates APFS which obviates a lot of this speculation.

John Galt wrote:

"Zeroing" a hard disk drive in the manner you propose has little if any practicable benefit. If it is your intent to obscure its prior contents, then what you really should be doing is to read from /dev/urandom for example.

I use zero there because some storage controllers will interpret that as a TRIM for flash, and because embedded servo tracking and density works far better than the sloppy mess that were floppies and that that sloppiness then necessitating multiple overwrites.

But if your adversaries are willing to invest in accessing any remaining data on an overwritten (modern) HDD, y’all should probably shred and slag the HDD.

I've never had any hard disk drives fail either 🤷🏻‍♂️

I have. Failures with old-time HDDs were way more entertaining and with way more debris and with better sound effects than do the newer HDDs, too. I still have a platter from an HDD failure, where a screw loosened came in contact with the platter and gouged the platter with spiral patterns. Newer HDDs usually just transmogrify into bricks, maybe with a faint whiff of magic smoke. Or ask the old ones about FASTRAND drum failures.

Ques 1

Is this workaround effectively the same as Disk Utilities option to erase free space (an option that I've given up on), but leaving a small amount of data unzeroed?

I believe so. Your method might even be preferable since I do not know exactly how DU does that.

The reported failure may be relevant.

Ques 2

If I cancel the process before it is finished, does that mean the data up to that point has been erased?

I believe so. What you describe as "erased" is more accurately described as "overwritten" though. How to determine what has been overwritten or not is unknown.

– I thought, "That should work".

I agree.

By the way your example Step 6 should be GB assuming you are overwriting a ±4 GB HDD. How storage capacity is measured on Apple devices - Apple Support is probably worth reviewing. It's a bit of marketing sleight of hand but everybody does it.

I've never had any hard disk drives fail either 🤷🏻‍♂️

John Galt wrote:

I've never had any hard disk drives fail either 🤷🏻‍♂️

I may be pushing that record with

dd bs=1024 count=(a stupendously large number) </dev/zero >~/Desktop/zero.txt

... so I'll let you know.

I expect it to finish in the next day or two.

☺️

I still have a platter from an HDD failure, where a screw loosened came in contact with the platter and gouged the platter with spiral patterns.

Nice. I hope you kept it as artwork.

Still waiting for my spinner to create that gargantuan file of nothingness. It'll be a while.

MrHoffman wrote:

I use zero there because some storage controllers will interpret that as a TRIM for flash, ...

I had intended to reply to Guy Burns but was too lazy to fix it.

Still waiting, but Time Machine said it couldn't back up. Progress!

BobHarris wrote:

…This is not really good for SSD's as they have a limited number of writes, and writing to every free block just insures you have reduced the life of the SSD

And SSDs necessarily erase deleted sectors as part of preparing for the next incoming write, and wear-leveling also means rewrites won’t target the same physical sector... With TRIM, sectors get erased just as fast as the SSD can churn its pending queue.

You are both just indulging my morbid curiosity.

Still waiting, while macOS is becoming increasingly grumpy. I haven't done this since Mavericks, in which I used up literally every single solitary byte just to see what would happen. Zero bytes remaining. Not nearly enough to take a screenshot, so I photographed it instead. It's here (somewhere).

All system efforts to reclaim space were exhausted. Log files gone, cache files erased, could not be created... etc. The Mac complained loudly, but it continued to work belying the oft-repeated admonitions to never ever let free space decrease < some arbitrary value or % lest dire circumstances ensue.

• No this is not a recommendation. It is theoretically possible to render a Mac unbootable by doing what I'm doing. And forget about TM. It will stop backing up — already confirmed.

John Galt wrote:

I expect it to finish in the next day or two.

Could be a week. Maybe more. Hard disk drives are slow.