[opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin

Talarus Luan sls.dev.sl.1 at sylea.org
Thu Oct 28 12:09:50 PDT 2010


On 10/27/2010 10:45 AM, Kent Quirk (Q Linden) wrote:
> Au contraire. Some people get very upset when an installer leaves any files behind that were created by the program automatically, such as log files.
Au contraire contraire. MANY people get VERY upset when an installer 
deletes files that belong to them that they directed the program to 
create, either explicitly, or automatically via an explicit setting. I 
have the original viewer 2 installed right now and am not going to 
uninstall it until I am DAMN SURE I have backed up my entire profile, 
specifically because of this asinine design flaw. If I didn't already 
know about it, I would be ROYALLY pissed off when it deleted years' 
worth of accumulated data; MY data. Despite having backups, there still 
will be incremental loss (data since last backup), and the hassle of 
having to restore said data. Other people aren't so lucky, not knowing 
to back up said profile data, or simply not doing backups (yeah, their 
risk, but there is NO call to intentionally manifest that failure in code).
> It's simply not true that the uninstaller shouldn't remove anything in the profile -- I have worked at multiple companies where leaving behind any breadcrumbs (anything that wasn't created by File Save) after an uninstall was considered a major bug.
Then that is multiple companies which promoted a SERIOUS installer 
design paradigm flaw. I can't say I envy you there.
Of the hundreds of customers I have developed software for over the past 
3 decades, if I had implemented such a design flaw in my uninstallers, I 
would have lost a lot of money, and potentially been sued by at least a 
couple of them. (btw, aren't anecdotal stories acting as appeal to 
authority logical fallacies fun?)

Look, this isn't hard to grok; it really isn't. Any collection of data 
which is created by or at the behest of the user is considered "user 
data". Implementations of a proper installer paradigm should NEVER 
*EVER* touch user data, either automatically or by default WITHOUT the 
full knowledge and consent of the user. That includes things like 
chatlogs, user-created folders underneath the program directory, user 
preferences, etc. This does not apply to things like temporary files, 
cache files/folders, or program data (because none of that is "user 
data"). An uninstaller also should inform the user of any files that it 
left behind, where, and why. Give the user information and control, and 
you don't have "very upset" users. Maybe "mildly annoyed" users, but not 
"I want to throttle the idiot developer that did this to me" users.

At MOST, an uninstaller, if it is hell-bent on trying to clean up 
*COMPLETELY* after itself, *must* inform the user that it wants to 
cleanup his/her user data, explain EXACTLY and IN DETAIL what is going 
to be cleaned, and leave the default for the option to NO (as in "don't 
delete my data!").

This is simply proper (un)installer design, and I am amazed that so many 
developers simply "don't get it", to the pain of their users (including 
myself). Deleting data is FAR more serious of an issue than leaving data 
behind. Once it is gone, it is gone; if it is left behind, the user can 
clean it up themselves. Anger from lost data >>> annoyance of having to 
break out the data dustbuster.

> Now I do think we can try do better; asking about deletion is on the Snowstorm backlog.
I sure hope so. <.<

> Installers are always tricky and hard to test, and very often the uninstaller comes "for free" with writing the installer. It's also specialized, platform-specific code, sometimes in a strange language, so it's not easy to find devs who want to work on it.
They are not nearly as tricky or hard to test as code itself. Yeah, the 
uninstaller is often auto-generated by the installer generator, but to 
not then go through it with a fine-toothed comb for verification and add 
application-specific changes to the uninstall script is just laziness, 
pure and simple. The "strange language" is often fairly simplistic and 
easy to manipulate with only a modicum of time and effort put into 
learning it. I would be extremely surprised to learn that there isn't at 
least one "installer expert" at LL, whose primary job function is 
building and testing installer packages (note I said "primary", not 
"sole"; let's not go there).

> There's work going on right now that will probably affect this, and we'll make sure this is considered.
It needs more than consideration; it needs to be done, period. It's 
improper and incorrect, it is a design flaw, and it needs to be fixed 
ASAP before it does any more damage to user data.

--TL


More information about the opensource-dev mailing list