[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