Welcome Image and Text

We believe in the long term value of Apple hardware. You should be able to use your Apple gear as long as it helps you remain productive and meets your needs, upgrading only as necessary. We want to help maximize the life of your Apple gear.

Main menu

Welcome to Low End Mac

Navigation Bar

Dealing with Resource Forks and .DS_Store Files on non-Mac Volumes

Leaman Crews - 2006.01.04

We all know that Mac OS X is a good citizen in mixed networks. Connecting to Windows shares, Linux NFS mounts, and FTP/SFTP servers is a snap. And the Sharing system preference panel makes it even easier for these other operating systems to connect to your Mac.

However, it sometimes seems that the Mac doesn’t really play so well with non-Mac systems. Connecting to a shared volume, your Mac will gladly leave behind pesky .DS_Store and resource fork files. It might also create a .Trash folder – or, even better, a “Network Trash Folder”.

Your Windows-using colleagues are likely to express irritation at these files and folders. While they are invisible on your Mac, they are definitely visible when viewed on their computers. In the best-case scenario, you may have to put up with a little grumbling. At worst, it may give the Windows users more fuel for the anti-Mac fire because Macs “litter” the network with “useless” files.

.DS_Store and Resource Forks

Just what are these mysterious files?

In essence, they help make your Mac a Mac. .DS_Store files keep track of icon sizes and positions and also allow you to do neat things like keep a picture as the background of a folder.

While .DS_Store came to the Mac with OS X, resource forks have been with us ever since the first Mac. They store information like the type of file and its creator code. For years this was how your Mac knew what type of file you were dealing with and what application to open it with – without having to use file extensions like the DOS/Windows world.

On Mac file systems (i.e., MFS, HFS, and HFS+), the actual data file and its resource fork are seen as one file. Copying a Mac file to other volumes can cause the data and the resource fork to be split into different files. (For a detailed analysis of the resource fork, check out Wikipedia’s Resource Fork article.)

The end result is a lot of junk generated every time you open a file on a non-Mac volume – or perhaps even by just browsing its contents.

The Desktop

The worst offender here is .DS_Store, which represents a huge step back from the classic days. In the classic Mac OS (up to version OS 9.2.2), the Desktop Database file kept track of icon and folder positions, among other things.

This was not a perfect solution, but it was very clever at the time the first Mac was released. The biggest problem was that the Desktop Database could get very large and unwieldy – or get corrupted. Hence the age-old Mac troubleshooting tip of “rebuilding the desktop”.

No matter the shortcomings of the Desktop Database, it was a lot better than creating an invisible file in every single folder that was ever opened, which is what OS X does.

Playing Well with Others

We may have to wait until OS XI to see Apple fix these shortcomings. Until then, there are a few things you can do to make sure your Mac continues to play well with others in your mixed environment.

As of OS X 10.4 Tiger, you can enter a Terminal command to prevent the creation of .DS_Store files on remote volumes. Apple has a knowledge base article explaining how to do this. However, it’s not a global fix, and it must be done for every user on a particular Mac.

For a more complete fix, check out Ross Tulloch’s BlueHarvest. This system preference panel works with OS X 10.3 Panther and 10.4; it disables the creation of .DS_Store and resource fork files in locations of your choosing, and it will also wipe out preexisting .DS_Store and resource fork files from certain folders if you like.

BlueHarvest is US$10 shareware, which may add up to a lot of if you need to deploy it on a large number of Macs. But for those who need to peacefully coexist in a mixed environment, it’s highly recommended.

Apple has acknowledged that .DS_Store files and the like are not always desirable, as evidenced by their knowledge base article. Here’s hoping that one day they will come up with a better system that will provide all the functionality without the mess of extraneous files.