116376 - installer deletes its own dir instead of the moz-dir

Status: RESOLVED FIXED

(SeaMonkey :: Installer, defect)

Description

[Marten ter Borgh]

Steps to reproduce this:
1) Download a mozilla tarball that includes the installer
2) Create a fake mozilla directory with some files in it:
$ cd /tmp && mkdir mozilla && cd mozilla && touch mozilla && touch mozilla-bin
2) untar the tarball and change to the directory that is created by the installer
( I usually do this in /tmp)
$ tar xfvz mozilla-i686-pc-linux-gnu-sea.tar.gz && cd mozilla-installer
3) Now, launch the installer from a bash-shell
$ ./mozilla-installer
Tell the installer to install mozilla into the fake directory you created under 2) 
4) Now change back to the bash shell you launched the installer from and press
ctrl+z , this will temporary interrupt the installation program.
delete the fake mozilla dir
$

Comment 1

[Marten ter Borgh]

(oops... hit the commit button by accident.. continued:)
$ rm -rf /tmp/mozilla
5) Re-activate the installer:
$ fg
6) I forgot to tell, but you must stop the insteller before confirming the
delete of the old mozilla dir - now, however, is the time to confirm (press delete)

Now something weird is happening: the installer will try to download xpi's from
the mozilla site. That isn't supposed to happen as we downloaded a full installer.
Exit the installer before it completes and check the mozilla-installer dir: it's
comletely empty! The installer evidently tried to change to the fake mozilla
dir, failed, but than emptied it's own dir.

This isn't a big problem; it's just stupid.

Comment 2

[Andrew Schultz]

Attachment: patch

the installer currently attempts to change directories into the destination dir
and do "rm -rf *".  This patch simply checks that the chdir succeeded before
running rm.  If it doesn't, it assumes that the directory is already gone.

Comment 3

[Daniel Veditz [:dveditz]]

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

r/sr=dveditz

This is a big improvement, but getting rid of "rm -rf *" altogether would be
even better -- way too dangerous (that's covered in other bugs).

Comment 4

[Andrew Schultz]

Attachment: throw up an error dialog too

ok, so rather than just not deleting when chdir fails, this patch puts up an
error dialog and returns back to the SetupType dialog window (instead of going
forward).  The user can choose another directory or (if they manually deleted
the directory), go on.

In order to get this to work, I had to clean up error handling.  Most
importantly, this patch bumps up the "LAST_ERR" from -625 to -630 so that
nsIContext actually reads in all the errors, and defined FIRST_ERR and LAST_ERR
in XIErrors.h where they are easily accessible when/if the list is updated
again.

Comment 5

[Andrew Schultz]

Attachment: include installer.ini

includes installer.ini changes

Comment 6

[Andrew Schultz]

Attachment: patch v4

ugh.  not all the installer.ini changes

Comment 7

[Andrew Schultz]

Attachment: patch v5

fifth time's the charm (perhaps 2AM isn't the best time to write patches!  :))

Comment 8

[Andrew Schultz]

Comment on attachment 141587 [details] [diff] [review]
patch v5

dveditz, can you review this expanded patch?

Comment 9

[Andrew Schultz]

Comment on attachment 141587 [details] [diff] [review]
patch v5

this patch will be insufficient once bug 234741 and bug 234744 land.  hidden
files get left behind.

Comment 10

[Andrew Schultz]

Attachment: invoke rm -rf "destdir"

this patch invokes rm -rf on the directory itself instead of its files so
hidden files get wiped as well.

Comment 11

[Benjamin Smedberg]

Comment on attachment 143168 [details] [diff] [review]
invoke rm -rf "destdir"

I'm not sure about this one... what if mDestination contains shell chars that
need to be escaped? Can we use execvp instead, and skip the shell?

Comment 12

[Andrew Schultz]

Attachment: use execlp

Comment 13

[Daniel Veditz [:dveditz]]

Comment on attachment 144749 [details] [diff] [review]
use execlp

sr=dveditz

Comment 14

[Andrew Schultz]

checked in by bz