About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Industry Watch


What's the matter with .DS_Store? The idea is good enough; the implementation is not.

Get It

Try It

.DS_Store is an idea implemented by someone aware of the potential for waste and chaos on user machines, who is aware of the concept 'sloppy programming', but who really doesn't give a damn.

.DS_Store files are Finder files. They're written with the dot ('.') in the beginning of the name so they won't intrude and scare. Any file beginning with a dot is invisible in Unix. .DS_Store files are stored for folders and in folders, on a per-folder basis, one file per folder.

.DS_Store files contain information about how a folder is to be represented onscreen. Some people like to have their Polaroid of Diamond Head in the background for their Pictures folder. Software vendors use .DS_Store files to make their disk image files attractive.

The idea is good enough; it's the implementation that screws up. Fortunately you don't have to be a computer genius to understand why; you only have to think about it for a moment. Follow along for the ride.

As we all know, the Finder allows one to configure settings for any folder on either an individual or global basis. If you go into the global folder settings, you are changing how all folders (ceteris paribus) will look. If you switch to individual settings, you are working on how only that folder will look.

The system is obvious: Somewhere outside the folders themselves the Finder keeps tabs on the generic global configuration for files: the size of the icons, what background image if any, and so on. This is not stored persistently in any folder; these are global settings, and apply to all folders - unless, that is, the Finder encounters a .DS_Store file locally.

The existence of a local .DS_Store in an individual folder is supposed to tell the Finder 'here we're diverting from the norm'. The Finder is supposed to read this file and make adjustments in display accordingly.

And this is how it works, and it does work. The problem is that it's implemented poorly - very poorly.

Consider: If the system were implemented correctly, and a user made no special settings for any individual folder, then no .DS_Store files would pop up on disk - right?

Wrong - and this is where the implementation rears its ugly head: Instead of just going about things in the logical and conscionable way, this ugly programmer included code to have the Finder ferret out and record all folders traversed throughout a session (up-time between two system startups). Nothing happens with this dirty information until next you boot, but when you do you can hear the evil routine at work as your hard drive starts thrashing. The .DS_Store routine is searching out all the folders it's become aware of since last and putting .DS_Store files in them - whether they're needed or not.

If a user has individual settings for a folder, then the Finder has to create a .DS_Store file - that is obvious. Putting this file in the folder itself is also the sanest way to deal with the issue. (Central storage would just be wrong and lead to infinite computational problems.)

But if the user should decide to revert to global settings, the Finder should delete the .DS_Store file. That would be the sensible thing.

Can one sense the HI hens' influence here?

A .DS_Store file takes a minimum of 6,148 bytes on disk. That's two disk clusters or 8,192 bytes (8 KB) including slack. As the Finder finds it a righteous prerogative to place these bastards anywhere it pleases, you can expect a theoretical disk waste of 8 KB multiplied by the total number of folders you have on disk.

Try navigating to 'Macintosh HD' and see if Finder will tell you how many folders you have on disk. It may take a while - the Finder is a bit slow. It has so many other things to do at the same time, like follow after you wherever you go and leave its droppings on your trail.

How do you get rid of .DS_Store files? You use a program like Xscan. Or you write yourself a cute little shell script. But what's important is that you cold boot repeatedly until they're basically gone. The Finder doesn't give up easily.

As the Finder writes these ugly things on startup, it's the information from the previous session that matters. If you clean them all away and then reboot, you're likely to see one only on your desktop, unless your global folder settings are identical.

A correlate of the above is of course that you also avoid use of the Finder. For anything the Finder touches - whether it be through an ordinary folder or through something as seemingly innocent as a 'Save As' dialog - gets dirtied with another turd of Finder do-do.

Unless you're a confirmed Unix freak, navigating your system exclusively with your Terminal.app is not going to be that inspiring - you need a new GUI tool which doesn't get the '.DS_Store runs' all the time. There aren't many; one is Path Finder, but that costs $35; another is Xfile which comes with another 18 file system utilities from the ACP and costs only $59.

But of course you can just run a 'containment script' from time to time to cut your losses.

Shell scripts that first find and identify .DS_Store files and then remove them may be a bit difficult to write; test being able to properly locate them before attempting to remove them. Then add 'sudo' so you get at everything.

Or try the free CLIX which has scripts to do the job for you.


Get It

Try It

You don't like cleaning up the little buggers in the first place? It can be done, but you need your own file browser.

Go into com.apple.loginwindow.plist in your Preferences directory and add the following.


Substitute the path for the file browser you've chosen.

And while you're at it, make sure you can quit Finder if ever it gets started up. Add the following to com.apple.dock.plist.


Postscript 2006-12-12: .DS_Store Redux

The individual responsible for .DS_Store has finally come out of the woodwork. Click here.

See Also
Xfile Test Drive
CLIX: Don't Sell a Man a Fish

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.