| Date: | September 17, 2007 / year-entry #346 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070917-00/?p=25103 |
| Comments: | 42 |
| Summary: | If the user chooses to uninstall your program, what do you do with the data your program kept in HKEY_CURRENT_USER, and other parts of the user profile? Should you enumerate all the profiles on the machine and clean them up? No. Let the data go. First, messing with the profiles of users that aren't logged... |
If the user chooses to uninstall your program, what do you do with the data your program kept in No. Let the data go. First, messing with the profiles of users that aren't logged on can result in data corruption, as we saw when we looked at roaming user profiles. Users don't like it when their data get corrupted. Second, the users might want to keep that local data, especially if they are uninstalling your program only temporarily. For example, maybe your program's installation got corrupted and the user is doing an uninstall/reinstall in an attempt to repair it. Or the user might be uninstalling your program only because they're going to be reinstalling a newer version of your program. If you deleted all the users' saved games, say, they are going to be kind of miffed that they won't be able to finish off the big boss that they've been working weeks to defeat. Now, if you want, you can clean up the per-user data for the current user (after asking for permission), but you definitely should not be messing with the profiles of other users. (Remember, this is my personal recommendation, not an official recommendation of Microsoft Corporation. I know that had I not included this explicit disclaimer, somebody would have written an article somewhere saying that "Microsoft says to...") |
Comments (42)
Comments are closed. |
Plus, maybe they’re uninstalling your software on computer A, but they’re still using it on computer B.
..Or maybe they’re uninstalling your software because they want it gone. And if you leave anything behind, they start blogging about how crappy your uninstallers are.
Sigh. It’s a no-win situation.
"you definitely should not be messing with the profiles of other users."
Yup. If I was on a unix-type system, and the BOFH decided to remove vim(1) because there were a dirty emacs lover, that would make me upset. However, if they also did a "find /home -name .vimrc | xargs rm" they would find themselves the target of a user revolt of the likes they had never seen! :-)
Don’t mess with the users’ configs. They may treasure them, have spent time, sweat, tears and blood in getting them just right, (e.g. finally turning off clippy) and they might need them again when they convince you to reinstall the program.
"And if you leave anything behind, they start blogging about how crappy your uninstallers are."
Per-user data is not program data. Such people merely need to be educated in the ways of multi-user systems. Just because they’re vocal, it doesn’t mean they’re right.
I know this probably isn’t the right forum, but what would you think of leveraging Windows Installer to remove personal settings? For instance[0], you could enumerate the profiles and install a RunOnce key that would notify the user that software was uninstalled and ask them if they want to remove their personal settings for it? The installer could drop off a mini-MSI file (or perhaps automatically generate it on Uninstall) that would take care of removing those registry keys and settings when the user next logs in.
[0] This is not really how I would do it — it’s just an example. A better option might be just have the MSIExec run when the user logs in to enumerate all applications uninstalled since the last login and present them in a check-list box and ask the users to check those apps for which the user wants to keep the settings.
"Per-user data is not program data"
I must disagree there. Most users consider that files they did not explicitly create are "program data" and should be cleaned up. In fact, they are probably unaware that the AppData folder even exists, and would certainly not deem the files that a program generated without their knowledge to be "theirs".
In the end, what matters to them is that their disk space get freed, and their registry doesn’t get bogged down by unused entries. This is not a matter of education, it is simply a matter of satisfying user needs.
Better still leave just enough of your uninstaller to uninstall the per user setting if chosen. Perhaps best to rename the entry in add remove programs to indicate it is removal only and just for the currently logged in user
One of our publishers has a list of requirements for software they publish, one of which is, effectively, every trace of registry that changed when our software is installed, must be undone on installation. They run install scenarios and then compare before and after hives to make sure we restore back to the original state, no matter what happens. This drives me NUTS for exactly the reasons you specify. I’ve not been able to convince them that this is a very bad idea. I’m glad you wrote this up as it will give me further ammunition to get them to remove this requirement. Thanks!
Thanks for the article, Raymond. Just to add closure to my suggestion-box topic, I ended up writing my own generic "Don’t show this again" dialog that saved the check box setting in a configuration file in Application Data. I just couldn’t bring myself to leave behind registry keys.
The program created an entry in the configuration file based on the user’s domain appended to their login name, if I remember correctly, and I just had to remember to replace certain characters with underscores. Worked out well.
@Karellen:
Not all the data that goes in %AppData% is that small. It could be the index for a desktop search software, or temporary files for a peer-to-peer application that must be kept between sessions.
Furthermore, I never said it should be removed without asking the user first. I simply said the user expect you to remove them through an uninstaller, since they are the program’s files.
Actually, I was just reminded of a scary case. After I tried out Joost some time ago (and weren’t too impressed with their program selection) and went to uninstall it, I wondered why I still was a bit short on disk space. And noticed they had 500+ MB of cached video floating around in my AppData folder. That’s the kind of thing I’d like to see cleaned up on uninstall. It doesn’t do any harm to remove (it won’t be missed, ever) and yet can be a pain for the user (taking up his disk space.)
"And noticed they had 500+ MB of cached video floating around in my AppData folder. That’s the kind of thing I’d like to see cleaned up on uninstall. It doesn’t do any harm to remove (it won’t be missed, ever) and yet can be a pain for the user (taking up his disk space.)"
Then it should be stored in the TempFolder directory or some other temporary storage or evident location. AppDataFolder is not an appropriate location to store/save temporary stuff.
Bad application design is not a good reason to start having your installer pooch my machine.
There is definitely no universal right answer, but there are universal wrong answers in my opinion.
Involving installation in application design mitigates a majority of these issues.
They are temporary because they aren’t finished, they are only temporarily incomplete.
Otherwise you’ll restart the download everytime you delete the ‘temporary’ download file!
Ah yes. After checking, each user does have a "Cache" shell folder separate from the "Application data" shell folder. Put caches in there, and they should be deleteable at any time when disk space runs low.
But JUST HOW is a user (or a program) supposed to go about removing other per-user data for a program that is no longer wanted or needed?
I am the only "person" who uses my computers, but I occasionally log on with a test username or another account username (like SQL_2005_Server) to do some task or other.
If I uninstall a program while logged in as my regular user, but I have used the program from more than one userid, am I no longer able, forever and ever, to get rid of the old, obsolete, and now useless per-user data for the other users, which might be taking up a lot of space?
Once I log in to those other userids, I can no longer run the uninstall program.
I think that there are a lot of cases where the uninstaller should ask you, and if you are an admin it should also ask about other users.
Think about the case of an admin switching from Thunderbird to some other mail client. There could be gigabytes of transient data locally that should be removed.
"As an administrator, I would not expect an uninstaller to remove all the other users application settings, as those users are not controlling the uninstallation."
Neither would I, but I would hope this uninstaller sets up a system which will ask other users with application data whether or not they would like to clean it when they first log on. The logistics of such a system, however, are often very complicated and extremely hard to get correctly (And might even be likened to malware, since an "uninstall" doesn’t really uninstall everything)
Shouldn’t the question be: why do we need an uninstaller in the first place ? Why do applications need to leave their junk all over the system ? Why should it be more complicated than e.g. dragging the application icon from your applications folder to the thrash can ?
"Why do applications need to leave their junk all over the system ?"
Because, for security reasons, non-admin users should not be able to write directly into the application’s directory. Because each user needs their own store of settings for each application. Because applications need to have a space to store stuff that should be transferred with a roaming profile and space for stuff that shouldn’t (e.g. data stores that are too large to transfer efficiently).
Some older installations I’ve stumbled upon have different ‘uninstallation’ modes like automatic and manual.
Manual allows you to remove everything and see it before you get rid of it. Unfortunately it is clumsy done: you can’t see the entire data (or the value!) as it doesn’t fit in the list!
I think this ‘manual’ uninstallation only removes stuff added at installation time, it doesn’t check for stuff at runtime.
I have also seen two variations of checkboxes that are opposites:
* preserve my settings (ticked by default)
* remove my settings
I prefer the second one and have it unticked by default.
Peter is right: it’s an odd situation, people expect uninstall to remove all traces. This is why we keep seeing companies releasing dedicated installers! (Arghh!) One analogy that pops into my head is a recycling bin for applications, the application isn’t fully removed until the user makes effort to remove it completely via the recycling bin.
Although this links the application itself and its settings too much and probably confuses.
It is? I thought it was because many EXE authoring tools are free, well-documented and easy to use, where as the MSI tools are none of these things?
But what then about eg. registrations? Say the application creates file type associations in HKCU during first run (it’s possible and works on XP at least) – those associations would be stale after uninstalling and might leave the user with some puzzling error messages?
I think I’ve read somewhere that Vista actually *supports* some kind of per-user associations and possibly class registrations, is that in the easily-uninstallable sense?
"Think about the case of an admin switching from Thunderbird to some other mail client. There could be gigabytes of transient data locally that should be removed."
I see what you’re saying, but a checkbox at the end of the installer saying "delete user data?" that wipes out gigabytes of my e-mail/contacts/whatever is pretty lethal – let alone the concept of wiping out gigabytes of other user’s data!
DrkMatter > I just hope I’m never a user on a system you’re administering.
If you’re the kind of admin who goes around deleting files from other users accounts just because you don’t think they’ll need them anymore, well, I don’t want to be anywhere near there. I don’t care if they’re backed up.
And if you can’t spare the disk space for some configuration data, that’s scary. That’s going to be, what, 2 or 3 orders of magnitude smaller than any actual user data? Pictures, documents, etc… are going to dwarf that sort of stuff by *miles*.
Just to clear this up…
User data:
actions, scripts, etc (think Photoshop)
savegames
exportable configuration
Program data:
Configuration files should be kept only in case they can be imported into the next program version without side effects.
Take a look at Total Commander, you can save wincmd.ini and use it in a newer version but it doesn’t get upgraded with new options and you don’t even see those in the UI so you don’t know they are there unless you delete config file and make a new one.
Installer should give you the choice to remove everything it put onto your hard drive.
Isn’t there a way to somehow sync the roaming profile on demand so that the changes end up where they are supposed to end up (master profile)?
What we have here is a failure to communicate.
There are many classes of data; caches, settings, and user-created are the basic areas that come to mind. Caches should be in common temp directories; setting should be in the registry (and small); and user-created data should be stored in their documents folder. The first two should probably be only cleaned up by the OS; the last by no one but the user.
"It could be the index for a desktop search software"
OK, caches are "user data" that can be deleted. I’ll grant that. But all caches should go in a temporary folder and should be deleteable *at any time* to recover disk space. The point of a cache is that it can be rebuilt.
"or temporary files for a peer-to-peer application that must be kept between sessions."
Um, strange definition of temporary? On many boxen I’m aware of, temp files are more transient than cached files. Certainly it’s normal for temp files/folders to be cleaned on reboot. Seeing how a program doesn’t know if it’s going to be reactived before the next reboot, I don’t see how such a program is going to do well if it relies on temp files hanging around between sessions. Perhaps you could explain this one a bit more?
"I simply said the user expect you to remove them through an uninstaller, since they are the program’s files."
But on a multi-user system, there are typically a lot more users than administrators, and the person doing the uninstallation (the administrator) is not a significant proportion of the people whose profiles you’re planning on deleting.
As an administrator, I would not expect an uninstaller to remove all the other users application settings, as those users are not controlling the uninstallation. They might have been on holiday or even sabbatical when the email went out asking if anyone was still using the app.
@Tom (and all the others too):
Start->Run: %comspec% /K cd /D %windir%inf && find /i "StubPath" *.inf
This will show some promising strings containing ‘PerUser’ or ‘InstallUserConfig’ and even ‘Remove’.
Windows already has the base mechanism! See MSKB 238441 and 250380 for example.
Maybe Raymond can shed some more light on how this is supposed to work?
Less is more.
I just wish MS would issue a statement on what the official policy is. Make it part of the "certified for Vista" program even. (in the meantime, I will point installer-guys to this page)
I had a long discussion with my tool vendor about their tendancy to wipe out all my settings upon reinstalling their tool… Grrr… I hate having to set up everything just the way it was again and again…
My settings are sacred and my own. Stay the h— away!
@Niels: in Windows 2000 and later, HKEY_CLASSES_ROOT is a merged view of HKEY_LOCAL_MACHINESoftwareClasses and HKEY_CURRENT_USERSoftwareClasses (HKEY_CURRENT_USER itself being a link to the ‘current’ user’s profile under HKEY_USERS). File name extensions, COM ProgIDs and COM classes are registered in one or both of these areas, the user-specific settings overriding the machine settings. You may have seen installers (particularly MSIs) asking if you want to install for the current user only or for all users. If authored to write to HKCR, an MSI will write to HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE respectively.
I don’t believe this has changed in Windows Vista.
Any components that explicitly write to HKCU or the user’s profile will be detected as needing a repair when an advertised shortcut (which invokes Windows Installer to check the product state before launching the program) is launched by a user that hasn’t launched the program before. You should explicitly author a RemoveFiles action to remove any folders you create in the user profile when the application is uninstalled. This is all caught by the Windows Installer ICEs (Internal Consistency Evaluators) if you validate your MSI, but sadly few users do. Version 3.0 of the WiX (Windows Installer XML) toolset automatically runs validation, so we see a lot of people on the list asking about this. The WiX construction to do it properly can be found at Rob Mensching’s blog here: http://robmensching.com/blog/archive/2007/04/27/How-to-create-an-uninstall-shortcut-and-pass-all-the.aspx.
This is the closest to an official policy from microsoft yet.
The best way is to disable install/uninstall software for all except administrators in multi-user enviroments
Don’t forget about Common Application Data. It’s better to have one 5GB cache than 10 500MB caches, plus you can clean it up on uninstall.
Another alternative is of course to put caches in %TEMP%. Let the disk cleanup wizard deal with it, if the user needs the space.
Chris @ Martial Development
It was supposed to say uninstallers, sorry!
"Installer should give you the choice to remove everything it put onto your hard drive."
And the data that the USE of the program has put onto your hard drive, IF it is easily findable in your Documents folder (and it should be), I suppose should best be left for cleanup by each user.
(Note that Outlook stores its .pst files in a not-easily-findable location. I predict that your half-gigabyte PST file, and every other user’s half-gigabyte PST file, would not be cleaned up by an uninstall of Outlook.)
Per-user settings (configuration options, settings, etc.) that the USE of the program has added to the registry should or should not be left alone in the registry, depending on each user’s preference for an uninstall to CLEAN UP, or a reinstall to not force you to re-customize the interface.
I suppose the adage that you can’t please all of the people all of the time is still true…
I suppose at first logon by another user after an uninstall, that user could be told that "Outlook has been uninstalled; do you want to remove the old e-mail data?"
But that flies against Raymond’s insistence that you not ask the user questions to which the user won’t know the answer. And I agree with that.
Oh well.
Sorry, that was kind of long-winded.
Some users prefer that an uninstall would do a complete cleanup of all traces of a program.
Other users wish that a later reinstall would not force them to re-customize their settings.
These two wishes are incompatible.
Why not throw all of the old user data into the recycle bin? That way, if the user realizes the app was uninstalled and something is missing it can be recovered for a short time. The next time the user actually needs space, the cleanup wizard will remove the old data.
The tricky part is getting the installer for the next version to find the files in the recycle bin and reuse them if possible.
Re: recycle bin – some of us don’t use that beast. I for ine wouldn’t like things to end up their ‘anyway’.
One more point to add is that with Roaming Profiles you can’t always change the user’s configuration data.
The problem is, we have user specific data that can be deleted (e.g. caches) and user data for the user (documents etc.)
Raymond Chen mondja: Mit tegyek a felhasználónkénti beállításokkal a szoftver eltávolításakor? (What
When you think about it, cache data will in many cases contain what is considered sensitive/personal data, and cannot be put in a all-user accessible location.
Also Common Application Data can’t be written to by limited users.