I did something stupid. I ran (something like) diskutil partitionDisk /dev/disk2 GPT HFS+ newdisk against the wrong disk. It was one of those moments where you realize what you've done, as you're doing it. So it only ran for (literally) about 0.25 seconds, or less, before being terminated (^c), like it was all part of a single motion. But it was long enough to trash the existing partition table.


I thought I'd be able to recover the original GUID partition table with testdisk, but apparently not. Maybe because it wasn't just damaged or erased, but already overwritten with a whole new GUID partition table, volume label, etc. I'm not really sure, I didn't write the software or study it comprehensively.


The data was largely, (if not completely) untouched, and easily recovered to a separate disk with photorec. Although it's not as if nothing happened, because the filenames and directory structure is all busted up. I mean, I'm greatful, but I can't realistically recatalogue 2TB of assorted files. If it were a project or something where I needed to extract some files, it woud be a godsend, but this is my perpetual dropbox where I hoard.. everything.

So, the data is obviously still there, but the pointers are gone. Is there a better way out of this situation? I feel there must be but at this stage I don't know enough about the ins and outs of data storage to do it, or to even really properly articulate my ideas about it.


PS: I'm not going to tell you what you can and can't do, but be careful if you're going to copy/paste commands like these. That's what happened to me, I couldn't remember the exact syntax, so I copied it from one of the questions/answers here on Stack Exchange, with the intention of altering it to suit my needs. Problem is, this included the invisible newline/linefeed character at the end of the formatted textbox, causing the command to execute as soon as it's pasted to a shell. Also, diskutil typically doesn't require elevated priveleges. So there's no warning, non prompt, it just happens.

  • After recalling old questions about disk recovery, did you not get a prompt from diskutil about it possibly making the disk un-bootable? Your GUID PT should have been /dev/disk0 and you should have gotten a prompt about the EFI partition. I can't find info on it in the man pages on when that is prompted. – Jahhein Feb 25 '18 at 13:42
  • @Jahhein Not really sure what you're talking about. Or what your point is. But no prompt; I don't think it was bootable anyway. Also, /dev/disk0 is typically the main (internal, physical) device. – voices Feb 25 '18 at 14:35

Because the GUID Partition Table was erased, there is no way to turn back. That GUID partition table is the last reference to data unless you can do some hardcore forensic data recovery.

Data recovery software that you can get rely on the GUID PT to never have been erased to locate data.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .