Top Ten Cleanups

Go down in the cellar and check up on the hired help.

There's many a site selling fancy software to do elementary things. It's a bit like the Vileda TV ads: do you really think a lady can swab her kitchen floor in a sexy evening gown and immediately be whisked away in a Porsche without even touching up her makeup? If you swallow that one, you're probably on your way to buying a few of those 'maintenance tools' already.

The difference between Unix - even the Mac kind of Unix - and other operating systems - and especially the old Mac - is that you can be your own janitor. You can get down in the cellar and take out the trash.

In the old days no one went down there and after a while things started to stink pretty bad.

Then too, think you've hired someone to actually clean out your cellar - you're going to pay them without going down and checking what kind of job they do?

That's exactly what you're doing if you believe the 'back of the box' with system maintenance tools. Even if you opt to use some of them anyway, you owe it to yourself to find out what it's all about and check how well they do their job and learn - in case one day you're left without hired help - how to do it yourself.

Following is a list of the 'top ten cleanups' for the Mac. It might initially be less than ten items, and it might grow to more over time. So welcome back.

.DS_Store

Probably the most aggravating junk file on a Mac system is .DS_Store. No other file stirs as much curiosity, and when people finally find out what they're all about, they often just want to get rid of the danged things.

There are plenty of tools out there that will, for a slight dent in your pocketbook, take away these critters, but it's completely unnecessary.

All you need to do is go to a command line (yes open a Terminal window) and type in the following.

sudo find / -name \.DS_Store -exec rm -i {} \;

A bit of an explanation of what each token means.

• sudo - you need to escalate to root so you can go places Finder could go but you ordinarily cannot.

• find - the powerful Unix command line tool that finds almost anything.

• / - this is the place to start the (recursive) search: root.

• -name - you're looking for a (case sensitive) filename match.

• \.DS_Store - the file name is '.DS_Store'. The '.' is 'escaped' as it can otherwise mean something else. A backslash in front means 'take the next character literally'.

• -exec - you want to execute a command line on any files found.

• rm -i {} \; - the command line to execute. The curly braces stand for the file found (with its complete path) and the semicolon signals the end of the command line. The backslash is again used to 'escape' a character - the semicolon.

Note that this version of the command will prompt you for each .DS_Store file found.

remove /.DS_Store?

If you answer 'y' (plus Return) the file disappears; if you answer anything else (or just hit Return) nothing happens.

The '-i' stands for - you guessed it - 'interactive', but you can whizz through by removing it.

sudo find / -name \.DS_Store -exec rm {} \;

You might want to try the interactive version first; after a while you'll get mighty tired of hitting 'y' + Return all the time; if you type the other command carefully, it will work a lot faster.

Language Project Files

Today OS X can install with a minimum of resources in languages you know you'll never use, but that's only Apple and a few other software houses that follow the rules. If your native or preferred language is English, most of the resources you'll need are in directories called 'English.lproj'.

But these aren't the only English language project files that can be found on disk, so it pays to be careful. There are names for British and Australian dialects you should be careful of removing if you think you'll need them, and there's another variant called 'en.lproj' which can fully substitute for 'English.lproj' and you don't want those gone either.

This task can take a few minutes to complete, but you'll find it's worth it. David Pogue estimated that your unused language project files can consume as much as 200 megabytes on a typical OS X install.

• Open a Terminal window and go to /Applications.

• List the contents and drill down into the first best app package you find there.

• Drill down to 'Contents/Resources' in the package and list again.

Some of the language project directories you're likely to find are:

• Japanese.lproj
• se.lproj (Swedish)
• zh_TW.lproj (Taiwan Chinese)
• French.lproj

Pick one out at random that you know you are never going to use and then go to another Terminal window and type in something like the following:

sudo find /Applications -name Japanese\.lproj -exec rm -fir {} \;

You add two flags to the interactive version this time to force deletions ('f') recursively ('r') as these are directories with their contents you'll be removing.

After you have the hang of this, try taking out the '-i' and just letting the system go.

And do this for every language project file name you find you know you never use.

Then do the same thing for your home directory.

sudo find ~ -name Japanese\.lproj -exec rm -fir {} \;

PkgInfo

This file in the Contents directory of every app package seems to take a mere 8 bytes on disk but appearances deceive. As the minimum disk allocation on OS X is eight disk sectors, it actually eats up four kilobytes.

What is it good for? It contains a four byte creator code and a four byte file type already found in the file Info.plist in the same directory. It's used only by Finder to speed things up a bit.

But Finder has had too many chances: it's time to make it work a bit harder.

sudo find ~ -name PkgInfo -exec rm -fi {} \;
sudo find /Applications -name PkgInfo -exec rm -fi {} \;

classes.nib, info.nib

Sloppy developers don't trim their 'NIBs' on release. NIBs are actually directories and are edited by Interface Builder. Only one of the three files in a NIB directory is actually used by the application at runtime: objects.nib. The other two can safely be removed, and Apple ship all their software this way today.

Other apps may have left some of this behind, so you clean it up for them.

sudo find ~ -name info\.nib -exec rm -fi {} \;
sudo find ~ -name classes\.nib -exec rm -fi {} \;
sudo find /Applications -name info\.nib -exec rm -fi {} \;
sudo find /Applications -name classes\.nib -exec rm -fi {} \;

[Note: with 'Tiger' Apple have got sloppy again, but the present discussion still holds. Ed.]

pbdevelopment.plist

Why this file follows release software when it does is a mystery. What it's good for is an even bigger mystery.

If you're curious, look inside one: all it has is the path to the development project - not on your computer but the developers' (as if they needed help finding their own code).

So back to the deletion boards again.

sudo find ~ -name pbdevelopment\.plist -exec rm -fi {} \;
sudo find /Applications -name pbdevelopment\.plist -exec rm -fi {} \;

Logs

Some logs are good to keep around; others lose their relevance. Crash logs can be good to send to Apple and others, but if you don't delete them they'll just accumulate.

Your crash logs are located in ~/Library/Logs/CrashReporter, so just do the following to clean that directory out.

cd ~/Library/Logs/CrashReporter;rm -i *

Here you can see the normal meaning of the semicolon: separating commands that are combined together on the same command line.

Temporary Files

You can also remove everything you're allowed to get at in your temporary directory.

cd /tmp
rm -fir *
remove 501? y
remove 501/Temporary Items? y

Update Prebindings

This is a cleanup operation you never need to do and never should do. Starting with OS X 10.2 the system automatically takes care of prebindings for you.

What are prebindings? They're computed addresses to other files (frameworks) that applications try to find at runtime. If the system doesn't know these other modules exist, it has to carefully test each and every external reference before giving the application the go-ahead to load; if they're found and stored in the program manually before the next launch then subsequent program loads can go a lot faster.

So even though there are still (sigh) a lot of utilities out there that try to lure with this feature, just ignore it: your system already does it a lot faster and a lot safer.

Periodics

A lot of people make a big thing out of making sure their periodics run all the time whether their machines are asleep or not. But before you take the plunge and invest in further skills (or further cash outlays) you'd better ask yourself the following:

• Have you ever had a serious system failure?

• If so, were the periodics helpful in recovering your system?

• Do you even know what the periodics are?

If your answer is 'yes' to the first question but only to the first question, you can safely skip this task: even if they could help you wouldn't know how to use them. They're a must for admins but it's doubtful they'd be of good to you.

Fix Permissions

Ideally this will never happen: ideally you'll never try to force a square peg in a round hole or put software in a directory where it doesn't belong. Sometimes no matter what the intended modes of files the destination copies get screwed up because of limited permissions at that end.

Disk Utility to the rescue: this program will check your /Library/Receipts directory for install packages lingering around and compare the file modes and ownerships of the source packages with their installed counterparts and correct whatever is necessary.

But of course this is predicate on your having the receipts still on disk and your being insistent in putting software where it really doesn't want to go - and/or mucking with modes so installs won't work correctly.

Then again, if you know you won't need those install packages anymore, you can just delete them and often get back huge amounts of disk space.

cd /Library/Receipts;sudo rm -fir *