I learned a hard lesson this past week about using the command cp in Mac OS X. You’ll want to know this too!

I needed to temporarily move a large directory from one drive to another on a Mac OS X server. The directory contained several subdirectories that had different permissions, so trying to do this copy from the Finder was going to be a pain. The solution was simple — do it from the command line. I quickly launched the terminal application and did the following command:

Server: sudo cp -r /Volumes/Drive1/BigFolder /Volumes/Drive2/

The copy complete several minutes later and on quick inspection, the permissions were intact. Everything looked good — until about an hour later. I got a call from the Tech Support Specialist from one of our buildings. One of the subdirectories in the directory I had copied contained installers for software for Mac OS 9 machines. None of the installers even launched correctly. Puzzled, I connected to the server to see for myself. He was right. They didn’t work. Strangely, all of the installers for Mac OS X software and Windows software worked perfectly.

After puzzling over this for a few minutes, I suddenly realized what the problem was. The resource forks of the files were gone. In the Macintosh operating systems, files have two forks — a data fork and a resource fork. In Mac OS 9, the resource fork is crucial information. It contains information about what kind of file it is, whether or not it executable, etc. Without that, the operating system doesn’t know what to do with it.

After doing a little research, I validated my theory. The cp command, being a UNIX command, doesn’t understand resource forks, so it simply strips them off when it copies files.

There was no way to fix my blunder, but there was a way to keep it from happening again in the future. The answer is the Mac OS X specific command named ditto. Ditto, if used with the -rsrcFork flag will preserve the resource fork of the file it is copying. I guess I’ll be using ditto from now on.

–Pete