234741 - installer should refuse to install to a non-empty, non-Mozilla directory

Status: RESOLVED FIXED

(SeaMonkey :: Installer, defect)

Description

[Andrew Schultz]

The installer currently checks whether the destination contains an existing
Mozilla installation and offers to delete the directory's contents.  If the
directory is pre-existing, but does not contain Mozilla, the installer gleefully
adds Mozilla to the directory.

This is bad and results in situations like bug 69153 and now bug 234479 where
people install to /usr/bin and things seem fine until they try to uninstall. 
The installer should prevent this from ever happening.  However, rather than
asking to delete the directory, the installer should just refuse to have
anything to do with it.  If the user wants to install to /usr/bin, they'll have
to go to the prompt and delete the directory themselves.

Comment 1

[Boris Zbarsky [:bzbarsky]]

There was a bug on this filed a few days ago suggesting that we refuse to
install to a nonempty dir unless it's got a file that flags it as "partial
installation done, then failed for some reason"....

Comment 2

[Andrew Schultz]

do you mean bug 234479?  that's "surgical upgrade", focusing on what to do with
old Mozilla directories.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  As long as you're aware of it.  ;)

Comment 4

[Andrew Schultz]

Attachment: patch

this prevents installation to a directory that contains anything other than "."
and ".."
directories that contain a mozilla-bin get wiped before this point.

Comment 5

[Benjamin Smedberg]

Comment on attachment 143166 [details] [diff] [review]
patch

We shouldn't prevent installing to a dir which has a plugins/ directory.

Comment 6

[Andrew Schultz]

(In reply to comment #5)
> (From update of attachment 143166 [details] [diff] [review])
> We shouldn't prevent installing to a dir which has a plugins/ directory.

The existence of a plugins subdirectory (under the current system) indicates
that the directory is Mozilla directory and should get nuked-from-orbit.  To
achieve this, "plugins" should be added as a LegacyCheck.  However, if a user
has a plugins directory and no mozilla-bin (the only way they could get to this
point), they are attempting a manual surgical upgrade, so that nuking-from-orbit
is exactly what the user does not want.

I hope to sort all of this out in bug 234479, which I'll steal from opi soon if
he doesn't fix it himself.  I wrote patch this first because it was simpler.

The options are:
1. fix this now and then bug 234479
2. wait for bug 234479
3. add plugins as a LegacyCheck.

#1 seems like the best option, but I'll steal bug 234479 now if you would prefer #2

Comment 7

[Andrew Schultz]

Comment on attachment 143166 [details] [diff] [review]
patch

> To achieve this, "plugins" should be added as a LegacyCheck.

hrmm.. I guess "Cleanup On Upgrade"/ObjectToIgnore (the Windows config.ini
terms) could be implemented here as another directory entry to ignore...  If
the user deleted everything but the plugins directory, the installation would
proceed.

I'll write up a patch for that.

Comment 8

[Andrew Schultz]

Attachment: patch with ObjectIgnore

this implements YALOSC (yet another list of strings class), nsObjectIgnore. 
it's nsLegacyCheck without a message.  These things need to get whacked, but
I'll do it in another bug.

This also stops doing different things for the lengths of section/key strings
and stops double-deleting sLegacyCheck when there are no legacy checks.

Comment 9

[Andrew Schultz]

Attachment: same patch with new files

forgot -N

Comment 10

[Alexander Opitz]

There is no iscussion on the Linux upgrade bug ... and that's why I hadn't done
anything and worked on MNG.

The user is a stupid person and you never know what he have done with his
mozilla directory.

So I don't know what will be the best way.

Comment 11

[Daniel Veditz [:dveditz]]

Comment on attachment 143494 [details] [diff] [review]
same patch with new files

sr=dveditz

Comment 12

[Daniel Veditz [:dveditz]]

This might be a good one to make sure makes it into the next milestone,
nominating blocking1.7

Comment 13

[Asa Dotzler [:asa]]

Comment on attachment 143494 [details] [diff] [review]
same patch with new files

a=asa (on behalf of drivers) for checkin to 1.7

Comment 14

[Andrew Schultz]

patch checked in by timeless