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...
Mac OS X Hints
http://hints.macworld.com/article.php?story=20051007000538357