A long time ago in a galaxy far, far, away there was Macintosh OS 9. In an effort to make file management easy Apple created a filesystem that used two physical files for each user document.
The primary file in the pair was called the “data fork” and contained the actual document contents. The second file was called a “resource fork” which provided metadata for the primary file. Over time Apple would need resource forks less and less but for some reason they still persist in OS X.
If you’ve ever used Terminal to
ls -al or copied files to a flash drive and viewed it in Windows you’ll see a hidden file for each visible file. Likewise, those hidden files have the same name preceeded with a period (.). Why the period? Files beginning with a period are automatically hidden in UNIX. Most (if not all?) Mac OS X applications don’t require a resource fork but they appear to be created anyway. Windows will never use the resource fork so they can be safely deleted.
When do resource forks become a PITA? When your Mac is connected to a Windows network share or you’re passing files along via flash drive. Most recently I copied a number of photos to a MiniSD card for use in a digital picture frame. The frame’s minimialistic OS tried to view every resource fork file which meant every other image threw up a “broken” thumbnail. Not ideal.
Now that we know resource forks are inconvenient outside of the Mac world how do we control them? The easiest method, thus far, is using BlueHarvest to automatically delete these files. Once installed, simply enable the deletion of resource forks from non-HFS disks (aka: “not a Mac” disk) and you’re good to go. I haven’t tested BlueHarvest exhaustively but it works as advertised. Using a MiniSD with 250 JPEG files it took BlueHarvest between 10 and 20 seconds to delete the resource forks. In contrast, using
rm -Rf .*in Terminal took less than five seconds. Perhaps I didn’t give BlueHarvest a required reboot, login, etc. but I’ll keep it installed and soon forget resource forks ever existed.