Scrambled external drive

I have an external hard drive which appears to have become scrambled, and I’d like to figure out how to fix it. I’ve tried Googling, but unfortunately, it seems that there are a wide variety of problems that can be described using the same keywords.

I think the problem started a couple of days ago. My mouse (plugged into the same USB splitter as the external drive) stopped responding for a few seconds, and at the same time my computer gave me a popup complaining that the external drive wasn’t ejected properly before disconnecting. Moments thereafter, the mouse recovered, and the external drive showed up again in Finder. I wasn’t doing anything that would have accessed the external drive at the time, and I’ve gotten that message before when, for instance, there’s been a momentary power outage and everything was fine, so I didn’t worry about it or double-check it.

Today, I did try to open some files on the external drive. All of the files still appear to be there, and the metadata like file size, thumbnails, and tags appears to be correct, but whenever I open one of them, if I’m able to open it at all, what I actually get appears to be segments from other files elsewhere on the drive.

I tried properly ejecting the disk and re-connecting it, but that didn’t change anything. I then opened Disk Utility, and told it to repair the disk, but it concluded very quickly and told me that it appeared to be fine.

I’m on a Mac, running OSX 10.9.5 . The external drive is a 500 gig OneTouch4, formatted as Mac OS Extended. Other details are available on request.

There’s nothing on there that I absolutely can’t afford to lose, but a lot of things that are really annoying to lose. Any help?

It sounds like the volume was partially corrupted, but it still intact enough to make it appear that it knows where the files are. This could potentially happen while the filesystem is journaling even if you aren’t running If you’ve gone through using the GUI Disk Utilities or CLI diskutil, you can try using the Unix fsck command sudo fsck_hfs -fy /dev/disk1s1), except replace disk1s1 with the name of your volume. You’ll have to run diskutil list to find out the name of the disk and volume. I’m assuming the drive is formatted in HFS but there are commands for other file system types as well, e.g. exfat, ntfs, et cetera.

If you do a web search for “Recover corrupted USB drive OSX” you’ll find a bunch of programs you can download free or for purchase to supposedly recover damaged volumes. I have never used any of these and can’t speak for their reliability or integrity, but there you go.


First of all, remove the drive and put it in a new USB enclosure.
Next, buy Disk Warrior, and use it to fix the drive. If DW can’t fix it, your only option is to manually scrape the drive and recover whatever files you can.

(That’s the short answer - there are many, many options from the command line, but in my experience, Disk Warrior does the best job at repairing directory damage.)

Before you run any further operations on the drive make a 1-1 byte for byte clone and work only on the clone. You can use dd to make the copy. Don’t run a series of repair utilities on the actual corrupted file system. You risk the damage simply becoming worse with no way of reverting to the base damaged system.

You can run fsck -n against the drive to get some idea of issues. As that explicitly won’t make any changes.

How do I tell fsck to check a particular drive? I can’t see any option for that in the man page.

When I run it with no other arguments besides -n, I get

$ fsck -n
** /dev/rdisk0s2 (NO WRITE)
Can't open /dev/rdisk0s2: Permission denied

I also don’t see an option in dd for copying an entire drive-- It looks like it just does individual files.

EDIT: And it looks like Disk Warrior costs $120, and I’m really not sure if it’s worth that much to me to recover this. Though I think I do have another external drive lying around to copy to…

I would be VERY interested in knowing just how exactly you remove an external drive from its enclosure.

It depends on the drive. Some of them are nicely assembled with screws and come apart easily. Others have ultrasonically-welded plastic enclosures that pretty much have to be destroyed to open. A hacksaw is generally sufficent.

The drive inside is almost always an ordinary SATA drive with normal power and IO connectors, so once removed, they’re easy to work with.

You need to point the commands at the appropriate partition on the drive.

If the drive is plugged in the mount command will list all the mounted partitions and the mount points.

% mount
/dev/disk1s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk0s2 on /Volumes/Macintosh HD (hfs, local, journaled)

The magic of Unix is that everything is a file. The device /dev/disk0s2 is a file if you want it to be one - so it can be used as both the source or target for dd, and is the target for fsck. If you are not comfortable with this dd is not your friend. dd will kill your files faster than anything you have if you get it wrong.

However you can also use Disk Utility to do most of this. In fact it is little more than a shim over the command line tools. Verify Disk is a call to fsck -n, and repair disk similarly calls fsck. You can get it to copy a disk or a partition. Check and fix error is a call to fsck. You are probably best advised to use Disk Utility.

Given running Verify Disk should show some errors, otherwise you have a difficult problem already.

To follow up - directly running fsck_hfs with some additional flags might be what is needed.

The permission denied error is due to not running it as administrator, or whatever it’s called in OS X. You need to put “sudo” before the command and it will ask you for your password and, assuming you have an admin account, it will run.

Although Disk Utility and fsck are worthwhile tools, Disk Warrior will fix directory damage that will cause both of them to cry “uncle!”

ETA: IMHO, from 32 years of Mac consulting.

Ah, I see now. How will I tell from the mount command which disk is which?

And speaking of “everything’s a file”, isn’t that true of directories, too (“folders”, for you youngsters)? I’m a bit puzzled by that one: If all of my files are mangled, then how is it that I’m still able to navigate my directory tree?

Anyway, I’ve got the drive disconnected for now. It looks like my next step is to plug in both it and a new drive (I’d been meaning to migrate over to a larger one anyway) and copy everything over, and then mess around with the new one. I’ll probably save this to do overnight, because I imagine that copying a third of a terabyte will take a while.

The mount command outputs the pair - device : mount point. The mount point is the path that the files within the device appear in the file system.

Devices under Unix appear in the file system as special files. (You can make more devices with the mknod command.) In reality the device file is a special entry that defines the type of device (the major device number) and the index number within the set of devices of that type (the minor device number). These are used to index appropriate tables of device drivers within the kernel. Of course you don’t need to know any of this. The manner in which everything is a file within the one name space is one of Unix’s “really neat ideas”. No stupidity with C: drives and the like. One name space. Lots of things are in the name space now. The OS Plan-9 took this idea to its fullest. Linux places processes in /proc and so on.

Files are allocated in blocks, and thus so are directories. Unless a directory holds a lot of entries it wont span more than one block. Your damage appears to be that you are getting a scramble of blocks in some files. So if a directory was affected you would lose the entire directory or not at all. HFS+ is a bit of a mess in that larger files have data managed via the extents b-tree, whilst the first bit of data is managed via the contents b-tree along with the meta-data.

fsck-hfs can rebuild the b-trees, and I suspect that this might be able to retrieve the mess.

OK, so I estimated that a copy of the disk would take about ten hours, and started it yesterday afternoon. It’s now been over 24 hours, and it’s still not done. The command I used was

$ sudo dd if=/dev/disk2s3 of=/dev/disk1s2

(having already determined the names via mount). The first time I tried it, it gave me an error message that said “Resource busy”, so I ejected the drive in Finder and tried again.

Is there any reason why it ought to be taking this long, or should I just ^c the dd command?

Likely that your drive is having read errors.
There’s another utility that I like that can circumvent some of those errors (or at least copy the non-corrupt portions of the drive in a reasonable time): Copy Cat X.

ETA: I strongly recommend moving the drive to another enclosure. I’ve seen plenty of USB-SATA interfaces go bad.

OK, just killed the dd command, and it reported that it had transferred about 40 gigs, out of nearly 500. So yeah, that wasn’t going to work.

Well, I was kind of hoping for a solution that didn’t involve use of a hacksaw, but it looks like I might need to do that anyway. But not right now: I’ve had it with this for the moment, and I don’t imagine anything is going to get any worse, while the drive is unplugged.

Depending on the problem with the hard drive, the freezer trick might work. The trick is to put the drive in a sealed plastic bag and then freeze it for a few hours. Then you take it out of the plastic bag and try reading it. You may find that it’s readable when its extremely cold. (It worked for me but then as the drive warmed, it was no longer readable. So I went through multiple freeze cycles before I got everything I needed from it.

The slowness of your dd command was likely due to your not having specified a block size. The default block size for dd is 512 bytes, which is much too small when doing a disk-to-disk copy. Most of your time is spent waiting for the right sector to rotate into position.

You might try again with something like

sudo dd if=/dev/disk2s3 of=/dev/disk1s2 bs=16m

Run it for a few minutes and see what the transfer rate looks like this way.


Well, that “not right now” turned out to drag on for a lot longer than I intended, but this past weekend I finally got around to it (incentivized by my internal disk running low on space, so I needed to get an external drive up and running to shovel surplus junk onto). So I plugged in a new drive, made a partition on it slightly larger than the old drive, and copied it over using Disk Utility. Then, I tried opening a few files, to make sure the (scrambled) data was there before I started trying to fix it, and… huh. That’s odd; those files don’t look scrambled at all now. Spent the rest of the day, off and on, checking files, and yup, they all appear to be back now.

So apparently, the only thing I needed to do was copy the drive. I’m not sure why or how, but hey, I’m not complaining.