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

A few tips on non-HFS data recovery System
I found out a couple things while doing a fairly hairy data recovery for a client. First, some background...

He had bought an external FireWire/USB hard drive which came formatted as FAT32. He left it as such, and then when the drive quit mounting, brought it to me for data recovery. I quickly discovered that it was a PC formatted disc and that it was too damaged for Disk Utility to fix -- and of course, none of my Mac utilities were going to be of any use. Even ScanDisk on our company's lone PC laptop couldn't do anything because the drive was actually failing. I ultimately used our copy of DataRescue for the PC (which is a spunky load of noodles to use, I'll tell you what) and managed to recover the client's data onto another FAT32 disk. The product actually works great and it recovered everything.

We then sold him a new hard drive, and to make future maintenance and potential recovery less problematic, I made sure it was formatted as HFS+. I then had problems copying from the recovery drive to the new drive -- I kept getting errors in the Finder saying that files I was copying didn't exist. I tried using ditto manually, and got the same errors. These appeared to be due to the AppleDouble ._ split resource fork files not being copied. It turns out a simple cp was able to copy every single file without a hitch. I didn't realize that ditto had such limitations when copying from non-HFS volumes.

And now for the actual hint! I realized that I had all these AppleDouble files that weren't going to do my client any good as-is. On a whim, I did an apropos fork in the Terminal, and discovered that lurking in /System -> Library -> CoreServices was a little binary called FixupResourceForks. When run on a directory, this app will traverse the hierarchy and copy all the AppleDouble files it finds back into the resource forks of the original parent files, also restoring the OS9 metadata -- file type and creator -- if present in the files.

You can do a man FixupResourceForks to get the syntax, but you have to run it explicitly from its location (or add /System/Library/CoreServices/ to your path). It also only runs on directories, and you can't turn off its hierarchical behavior -- so you have to be careful if you only need to restore certain files. Apparently this binary has been around since at least 10.3, and is meant to complement /Developer/Tools/SplitForks. Google FixUpResourceForks, and you'll find a bunch of info on how folks have used these tools and rsync to script backing up to and restoring from NFS and UFS volumes. Just when you think you've found every little gem...
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[14,840 views]  

A few tips on non-HFS data recovery | 4 comments | Create New Account
Click here to return to the 'A few tips on non-HFS data recovery' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A few tips on non-HFS data recovery
Authored by: osxpounder on Oct 10, '05 02:21:48PM

mike666, thanks very much for taking the time to submit this informative hint. I just started using an external FW drive that's formatted FAT32, and I'll keep your hint handy. I also appreciate hearing about DataRescue for the PC. Since I'm using the drive on a Mac sometimes, and sometimes on a PC, I expect your tips will prove useful.

---
--
osxpounder



[ Reply to This | # ]
A few tips on non-HFS data recovery
Authored by: kaih on Oct 10, '05 05:11:35PM

It is worth mentioning also that cp, rm etc under Tiger are all now properly resource-fork aware - meaning if you copy a file with cp, the resource fork (if present) will be handled correctly, you don't have to explicitly use ditto.


---
k:.



[ Reply to This | # ]
A few tips on non-HFS data recovery
Authored by: kraigmason on Apr 08, '06 12:01:42PM

Hello Mike666...
I have run into a very similar problem with my own backup drive.
unfortunately i cannot get the FixupResourceForks command to work.
it just goes right to the command prompt again as if there is nothing to fix.
In the case of my drive directory the resource fork file is in its own folder.
The drive did not always appear this way.
in the root directory the fileid.dat & finder.dat files are now visible.
it used to work like a standard mac disc...where ICONS were present and you could simply open up any project from the drive.
something got out of sync..or something and now, nothing.
i see you say you work for a data recovery company.
any way i can hire you to save my data?

thanks,


kraig
kraig.mason@gmail.com



[ Reply to This | # ]
A few tips on non-HFS data recovery
Authored by: dkallan on Oct 09, '07 01:13:35PM

kraigmason wrote:

I have run into a very similar problem with my own backup drive.
unfortunately i cannot get the FixupResourceForks command to work.
it just goes right to the command prompt again as if there is nothing to fix.
In the case of my drive directory the resource fork file is in its own folder.

If the resource forks appear as files of the same name in a separate subdirectory (.AppleDouble), then this is a legacy of netatalk, the UNIX-based AppleTalk file sharing server. This "AppleDouble" format is not the actual AppleDouble v1/v2 header file format used in other contexts, which is exactly what FixupResourceForks expects and would explain why FixupResourceForks passed over these directories.

My response may be a little late, but you do have options. If you download and install the latest netatalk code (http://netatalk.sourceforge.net/), you can use a utility included with netatalk called "megatron" (oh, nerds rejoice!)--or technically one of its aliases, "macbinary"--to convert this netatalk .AppleDouble folder format into a MacBinary .bin format: macbinary <filename>, where <filename> refers to the data fork file in the directory that contains the .AppleDouble subdirectory. Note that the data fork and resource fork files must have the same name (hopefully they have not been separated during various file moves over the years).

The result is a .bin file in your current working directory. Note that the timestamps on the .bin file will reflect the current time, not the timestamps of the original file. However, the original timestamps are preseved within the MacBinary metadata and will be restored when the file is unarchived. MacBinary .bin files can be opened using various archival tools. If you use OS X and have the .bin file on an HFS volume, you can convert it directly into a native split fork HFS format using Apple's macbin command: macbin -d <filename.bin>

If you use OS X and have DarwinPorts/MacPorts installed, you can configure and install netatalk easily using the sudo port install netatalk command.

These commands may be scripted to find and convert a multitude of .AppleDouble directories, but it is always a good idea to back up your data first.

Cheers,
Daron Kallan
New York, NY, USA



[ Reply to This | # ]