OS X and program removal

September 20, 2005 7:08 AM

How does one cleanly and completely uninstall a program in OS X? Not all programs that I've installed can be completely removed simply be deleteing the program from my hard drive. Some seem to install files in other locations. Is there some sort of tool that makes it easier to ensure complete removal of a program and its stray files?
posted by missed to computers & internet (17 comments total)

Usually running the program's installation tool again gives you the option of doing an uninstall in the cases where the program installs things in odd locations.

But, this is something I too have been curious about. Is there software like that available for Windows that watches installations as they proceed and produces a log of what went where? I assume this would be much easier to accomplish under Tiger by hooking in to the filesystem's automatic change notification-thingy.
posted by odinsdream at 7:10 AM on September 20, 2005

I actually use Spotlight. That is not automated, but works fine in Tiger.

Some applications have no files outside of their package. Others leave behind the stray preferences file in your home directory. Still others leave something behind in the /System folder. Those kind are more likely to have an uninstall program, but not all do.

But either way, deleting things left behind in Spotlight left behind seems to work. I just search for the name of the application with Spotlight.
posted by teece at 7:43 AM on September 20, 2005

I found DesInstaller to be a good tool for uninstalling .pkgs. There's also a program called Pacifist that will show you the file contents of a .pkg.

Not exactly what you're looking for, I don't think, but these are good tools to know about.
posted by autojack at 7:44 AM on September 20, 2005

I'm not sure such an app exists. If a program doesn't have an uninstaller, the developer's site usually lists the files (and their location) you need to remove.
posted by btwillig at 7:51 AM on September 20, 2005

Have a dig around the Library folder in your Home folder, particularly in Application Support and Preferences. Preference file names are in Java reverse domain name format (eg. com.metafilter.appname.plist), so it's easier to find them if you know that application developer's web address.

If the program didn't use an installer (most don't), it's unlikely they'll put files anywhere else, but there are no rules governing this, so it'd be hard to write a program that reversed it.
posted by cillit bang at 8:22 AM on September 20, 2005

There is no standard or 'community favorite' application of this type, no, and while musing about it with co-workers, I figure the primary reason is because the majority of apps are well-behaved.

Most of them do leave junk in ~/Library/Application Support, but those are almost always small text files, plists and what have you, so it's not all that awful and if you're a neatnik you know to go in there and remove folders after junking an app.

As others have said, for any more intrusive installations, they usually provide an uninstaller, and for the small number that are both intrusive and don't play nice (e.g. no uninstaller), I'd say we're no worse off than Windows or Linux, in that there will always be a small minority of application packagers who just don't play by the rules.
posted by cyrusdogstar at 8:28 AM on September 20, 2005

Oh, and I almost forgot--I had expounded upon my reasoning at the start of my previous post, during aforementioned discussion. If you were to create a Windows-like installation management system for OSX, you'd need to require that all application packagers conform to that standard. Obviously not everyone will (like I said above).

Therefore, I think this is why Apple didn't go the 'central program installation registry' route, because either way, you have to require that everyone conform to a standard. If you factor that out, all you're left with is A) possibly cumbersome central registry app for managing installations, or B) an elegant 'opaque folder' approach which allows simple drag-n-drop installation/uninstallation. Clearly Apple feels the latter approach is more user-friendly, and I think most of us would tend to agree.
posted by cyrusdogstar at 8:35 AM on September 20, 2005

... you'd need to require that all application packagers conform to that standard. Obviously not everyone will (like I said above).

Not necessarily. It might not be very user-friendly, but with the filesystem used in Tiger, you could probably write a pretty effective watchdog system that, when activated right before an installation and deactivated right afterwards, could list the files that were modified. Of course, you'd get false positives unless there's a method for determining which process was responsible for the modification/creation. I'm not sure.
posted by odinsdream at 8:43 AM on September 20, 2005

There are already programs that do that, odinsdream, for Linux. Native Linux filesystems don't have Spotlight, so it seems it'd be even easier in OS X.

But the Linux app I've used is called "checkinstall." It's a command line app. I wonder if it would compile on Darwin?
posted by teece at 8:57 AM on September 20, 2005

True, you could certainly come up with creative and automated ways to do it, but like you pointed out, I doubt any of them would be foolproof. And what would such a system really gain us, anyway? Always a good thing to keep in mind.

Now, yea, a really poorly-behaved app could spew large amounts of data (image files, overly verbose and non-rotated log files, etc) around, but I'd wager that the average amount of detrius an app leaves behind when the .app is removed would be well under a megabyte, and in folders a normal user isn't going to be walking around in anyways. Who's really going to notice?

And if someone is really anal-retentive about having a super-clean filesystem, I don't think they'd trust an automated uninstaller anyways.

Sorry if it seems like I'm being anal-retentive about the issue, I'm just intrigued by system design and general HCI, so I try to thoroughly explore decisions of this nature.
posted by cyrusdogstar at 9:01 AM on September 20, 2005

teece, aside from the fact that it creates a Slack, Debian or RPM package for the apps it keeps track of, it should compile on OS X just fine. Unless I'm a total moron, as long as you have the source and it doesn't link to any incredibly platform-specific code, anything will build on OS X that builds on Linux or BSD.
posted by cyrusdogstar at 9:03 AM on September 20, 2005

There's not much point though.

Cleanliness is nice, and I think it's great to go through your Library folder now and again to clean out old detritus, but that's the only reason to get rid of 99% of files that appear related to a new app on your Mac.

I've never seen an application that relies on additional "hot" files in different parts of the system that didn't have an uninstaller.
posted by mikel at 9:12 AM on September 20, 2005

If an application uses the standard Mac OS X installer, it creates a receipt (BOM) in /Library/Receipts. The Disk Utility uses these files to repair permissions. For this reason any app that uses Installer VISE or another non-Apple installer also typically leaves a receipt. You can dig around in there to find out what got installed and where. Probably there would be some automated way to remove an app using its receipt, but there is rarely any reason this is necessary.
posted by kindall at 9:54 AM on September 20, 2005

One reason I can think of is that a shareware application might leave a file in an unspoken location in order to determine whether a time limit has expired or not. Uninstalling the application using its own uninstaller could intentionally avoid removing this file so that simply reinstalling the application wouldn't allow the user to restart the timer.
posted by odinsdream at 10:23 AM on September 20, 2005

At the risk of sounding like a corporate shill, if you're willing to pay to resolve this problem, Matterform Software has an app named Sonar that tracks changes to your harddrive. Take a snapshot before installing, take one after and compare. That should help you to understand what installation packages are depositing on your machine. I am not affiliated with Matterform and have not used this software but have used other products from them that I liked.

They also have a demo version (but it doesn't display hidden files).


posted by badmouth at 1:22 PM on September 20, 2005

Pfft, why use that when you can just use 'find' in the terminal? Install the app, then find all files modified in the last minute (or however long the install took). Most of them will be the installation files.

# find / -mmin -1
posted by cyrusdogstar at 2:42 PM on September 20, 2005

I second teece's comment. Just do a cmd-space or cmd-F in Finder, type in the name of the application, and you should see all files and folders related to the application. Send these to the Trash and you're done.

The only files this misses are invisible files sometimes created for registration purposes. Some applications will create an invisible file (filename preceded with '.') that contains information about when you first launched the application or your registration code, if you have one. You can find these by using an application that allows you to view invisible files in the Finder (I use Cocktail, but there are freeware apps available, like OnyX. The thing about these files is that they rarely have filenames that are related to the associated application, so you have to guess. They are usually in the ~/Library/Preferences or /Library/Preferences folder, but sometimes show up in the Home folder. If you are uninstalling immediately after installing, you can do a search of invisible files and look for the date/time created or modified to pinpoint the files. Otherwise, I guess you could make a note of what time/date you installed the app in question. YMMV. Be careful, as not all invisible files are these type, and some are necessary for indexing of your Home folder/Hard drive/etc.
posted by al_fresco at 9:57 PM on September 20, 2005