Closed
Bug 116376
Opened 23 years ago
Closed 21 years ago
installer deletes its own dir instead of the moz-dir
Categories
(SeaMonkey :: Installer, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: marten, Assigned: ajschult784)
Details
Attachments
(1 file, 6 obsolete files)
1002 bytes,
patch
|
benjamin
:
review+
dveditz
:
superreview+
|
Details | Diff | Splinter Review |
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 $
Reporter | ||
Comment 1•23 years ago
|
||
(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.
![]() |
||
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•23 years ago
|
QA Contact: bugzilla → ktrina
Assignee | ||
Comment 2•21 years ago
|
||
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.
Assignee: slogan → ajschult
Assignee | ||
Updated•21 years ago
|
Attachment #141518 -
Flags: review?(dveditz+bmo)
Comment 3•21 years ago
|
||
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).
Attachment #141518 -
Flags: superreview+
Attachment #141518 -
Flags: review?(dveditz+bmo)
Attachment #141518 -
Flags: review+
Assignee | ||
Comment 4•21 years ago
|
||
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.
Attachment #141518 -
Attachment is obsolete: true
Assignee | ||
Comment 5•21 years ago
|
||
includes installer.ini changes
Attachment #141584 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #141585 -
Attachment is obsolete: true
Assignee | ||
Comment 7•21 years ago
|
||
fifth time's the charm (perhaps 2AM isn't the best time to write patches! :))
Attachment #141586 -
Attachment is obsolete: true
Assignee | ||
Comment 8•21 years ago
|
||
Comment on attachment 141587 [details] [diff] [review] patch v5 dveditz, can you review this expanded patch?
Attachment #141587 -
Flags: review?(dveditz+bmo)
Assignee | ||
Updated•21 years ago
|
Attachment #141587 -
Flags: review?(dveditz+bmo) → review?(bsmedberg)
Assignee | ||
Comment 9•21 years ago
|
||
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.
Attachment #141587 -
Attachment is obsolete: true
Attachment #141587 -
Flags: review?(bsmedberg)
Assignee | ||
Comment 10•21 years ago
|
||
this patch invokes rm -rf on the directory itself instead of its files so hidden files get wiped as well.
Assignee | ||
Updated•21 years ago
|
Attachment #143168 -
Flags: review?(bsmedberg)
Comment 11•21 years ago
|
||
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?
Assignee | ||
Updated•21 years ago
|
Attachment #144749 -
Flags: review?(bsmedberg)
Assignee | ||
Updated•21 years ago
|
Attachment #143168 -
Flags: review?(bsmedberg)
Updated•21 years ago
|
Attachment #144749 -
Flags: review?(bsmedberg) → review+
Assignee | ||
Updated•21 years ago
|
Attachment #144749 -
Flags: superreview?(dveditz+bmo)
Comment 13•21 years ago
|
||
Comment on attachment 144749 [details] [diff] [review] use execlp sr=dveditz
Attachment #144749 -
Flags: superreview?(dveditz+bmo) → superreview+
Assignee | ||
Comment 14•21 years ago
|
||
checked in by bz
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•