Closed
Bug 210731
Opened 21 years ago
Closed 21 years ago
Setup should delete target installation dir on upgrade
Categories
(SeaMonkey :: Installer, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ssu0262, Assigned: ssu0262)
References
Details
(Keywords: fixed1.4.1)
Attachments
(3 files, 5 obsolete files)
33.06 KB,
image/jpeg
|
Details | |
14.90 KB,
image/jpeg
|
Details | |
91.55 KB,
patch
|
Details | Diff | Splinter Review |
[I did a quick query in bugzilla and could not find this bug filed. If there is
a bug already filed on this, please dupe this against it.]
There are lots of people running into crash at or browser not running correctly
at startup. Almost all of these problems are caused by 3rd party components
(having been installed by the user) not being compatible in one way or another
with the latest browser version trying to be installed.
A solution is to have Setup detect such an upgrade (installing ontop of a
previous installation of the browser regardless of version) and prompt the user
that deleting the target dir before installation begins is highly recommended,
else problems will arise.
We need to not delete the following from the target dir:
file: install_status.log
dir: plugins
dir: uninstall
Initial patch. Strings needs to be cleaned up/reworded, but it works as is.
[note to self: need to apply the config.it part of the diff to the ns tree.]
Comment 2•21 years ago
|
||
Just to be clear, only contents of DIR should be deleted, not the root
installation DIR. If my first install of Mozilla was on 1-1-1999, my dir should
show 1-1-1999 until I delete it myself.
right, since not everything is deleted, the root dir will still be around. Even
if everything is deleted, it should still exist.
Comment 6•21 years ago
|
||
the indent in the uninstall looks weird.
This patch will show the dialogs in the images attached above.
This patch (compared to the previous one) also fixes the uninstaller. The
uninstaller will now also prompt the user in the case where there are still
files left after the uninstallation is done.
Attachment #126528 -
Attachment is obsolete: true
Attachment #126581 -
Flags: review?(dveditz)
The patch will also detect if the user had installed into a dir within the
%windir% folder. If so, both the installer and uninstaller will inform the user
of this and not perform the cleanup/delete.
- Deleting target installation dirs on upgrade is a tricky thing. For instance
under Linux this behavior is already implemented, rendering entire systems
unusable see bug 69153.
- According to the initial description this would also fix bug 200651.
- What if plugins are not forwards compatible? I don't know how likely that is
and therefore i do think that indeed the plugins folder should be spared.
- What if people select a wrong installation folder, eg. c:\program files\ or if
they for some reason store other stuff in their Mozilla folder as well?
- What's the target for this? If this still makes 1.4 and next version of
Netscape would be VERY convenient.
Comment 10•21 years ago
|
||
Doesn't seem to work on my Windows custom install. No dialog and immediate crash.
Assignee | ||
Comment 11•21 years ago
|
||
Mark, can you elaborate on what you meant in your comment #10? What's not
working? This patch hasn't landed yet.
Patrick, regarding your comments:
> - What if plugins are not forwards compatible? I don't know how likely that
> is and therefore i do think that indeed the plugins folder should be
> spared.
the plugins format is a standard, common format. future browser code should be
backwards compatible with older plugins AFAICT.
Cc'ing PeterL in case I'm wrong.
> - What if people select a wrong installation folder, eg. c:\program files\
> or if they for some reason store other stuff in their Mozilla folder as
> well?
I can place a check for [program files] and [common files] (exact match of course).
Comment 12•21 years ago
|
||
Oops. Sean I thought this was a blocker for 1.4. I apologize.
Comment 13•21 years ago
|
||
Message Cleanup On Upgrade:
A previous $ProductNameInternal$ installation has been found in the chosen
destination folder.
It is highly recommended that this destination folder be cleaned up prior to
installation, or instability of $ProductNameInternal$ may arise due to
potential incompatibility of 3rd party files.
Allowing setup to cleanup this folder will not affect your profiles,
preferences, or mail messages. However, a reinstallation of any 3rd party
files previously installed will be necessary.
--
I don't like:
arise due to potential incompatibility of 3rd party files.
I think you are either missing a 'the' before potential, or should
change "potential incompatibility of" to "potentially incompatible".
Please make sure someone who cares about English reads and approves of the text
that you choose.
I'm also not sure that you need the 'potential*' bit, i think you have enough
fuzziness earlier (near "may") in your warning.
--
That said, is there a reason to delete more than:
bin\*.dll
bin\chrome\overlayinfo
bin\components\*.*
[where bin is the target install dir]
(overlayinfo is for kicks, mozilla should clobber it on its own if the jars
have reasonable timestamps)
re comment 9: for a long time there was a adobe svg plugin which used unfrozen
xpcom apis, it worked until we changed then, after which it led to many crashes.
wrt checking for program files/common files, i'd much rather a check for:
is special folder and a check for matches those strings (Program Files, Common
Files). Note that just string matching will suck on any localized system. And
just because someone has one program files doesn't mean they don't have more. I
have at least 3, possibly more.
Here's my definition of special folder:
1. attrib +s
2. is listed in
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell
Folders
3. is listed in
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell
Folders
4. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
5. is listed in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
Under anything named *Path, *Dir or *PathUnexpanded or *DirUnexpanded
6. is listed in %PATH%
Personally I'd also check:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools Location
4 is a bit special
a. DocZilla's installer managed to mess up:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\D:\mozilla\DocZilla install version\mozilla.exe
so you should dig through keys looking for (default) or Path.
b. Path is like %PATH%, it's a list of directories, most things will only have
one directory but some may have more so don't treat it as if it's the path to a
single directory.
c. In the event things turn up in these places you can simply warn about the
references.
d. If the installer happens to know that it's going to write to a given key,
then it may ignore it, e.g.:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\Mozilla.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\Netscp.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\Netscp6.exe
Comment 14•21 years ago
|
||
See Bug205277, Bug 211363, Bug 211484, Bug 211353, Bug 211458, and Bug 211602
Instead of deleting thes files, shouldn't the program alow them to be moved to
another directory?
Comment 15•21 years ago
|
||
Wanted for 1.4.1 and 1.5. Dan, can you help us out with a review here?
Flags: blocking1.5a+
Flags: blocking1.4.x+
Comment 16•21 years ago
|
||
Comment on attachment 126581 [details] [diff] [review]
patch v1.0
Does this patch also do away with the annoying "This directory doesn't exist,
create it?" pop up? If you haven't changed that already it should be combined
with this patch since that dialog implies the opposite of this new dialog:
in that one re-using a directory is "normal", in this patch re-using a
directory gets you a big scary delete warning.
The following text comments apply to all variants of the config.ini template
>-UsageMsg Usage=Usage: %s [options]\n [options] can be any of the following combination:
[.....]
Oy, that's horrible--a line over 1400 characters long, >1700 columns counting
expanded tabs. Lines this long may break some old tools--but more importantly
they're just plain hard for humans to deal with. Couldn't you create something
like your usual "UsageMsg Usage<N>" routines to concatenate multiple lines?
Plus you've had to write a text-\n to CRLF conversion routine that you wouldn't
otherwise need if you just stuck an EOL between separate config entries.
>+Message Cleanup On Upgrade=A previous $ProductNameInternal$ installation has
>+ been found in the chosen destination folder. [...]
This could be simply "...chosen destination" or "...chosen folder". In fact,
since the selecting UI says "Select a directory" and doesn't use the word
folder anywhere it should probably be "chosen directory" unless you're going
to change everything else to "folder".
>+It is highly recommended that this destination folder
"this directory"
>+ be cleaned up prior to installation, or instability of $ProductNameInternal$
>+ may arise due to potential incompatibility of 3rd party files.\n\nAllowing
>+ setup to cleanup this folder will not affect your profiles, preferences,
>+ or mail messages. However, a reinstallation of any 3rd party files
>+ previously installed will be necessary.
I'm now frozen in fear. Do I risk pushing the button and deleting things?
Do I dare leave these nasty 3rd party files, whatever they are? Why
did you mention my mail? Maybe I should _really_ worry!
My choices are "Delete" and "Ignore". Delete what? Ignore what? "Clean" (or
"Clean up") and "Skip" might be better, but it would be better yet to reword
this so the action we want users to take appears normal and non-scary.
A previous $ProductNameInternal$ installation has been found in the
chosen directory. Unrecognized 3rd party components will be removed
from this directory to prevent version incompatibilities and will
have to be re-installed.
Continue Skip
Something like that is a step in the right direction, I think. Would
it be possible to run the text by one of the help writers?
>+Cleanup On Upgrade Path Box String=Path to be cleaned up:
"directory" instead of "path" for consistency, but if you go with
my suggested warning text probably just "Destination directory:"
>+Message Cleanup On Upgrade Windir=Setup has detected that the previous
>+ installation of $ProductNameInternal$ was installed to a folder within
>+ your Windows folder. Setup will not attempt to cleanup the previous
>+ installation of $ProductNameInternal$ due to the potential removal of
>+ critical system files.
Looking at the logic users won't see this message until after they
hit the "Delete" button (or "Continue" in my suggestion). It
would be better in this case not to offer the delete choice
since we know we won't honor it anyway. In fact if the destination
directory is in c:\windows (and perhaps expanded to include
other known silly places) we should warn the user when it's
chosen whether or not there's a previous installation.
You have chosen to install into a directory used by
the windows operating system which may interfere with
the operation of $ProductNameInternal$, Windows, or
both. We recommend you chose a different directory.
Back Continue
>Index: packager/win_gre/uninstall.it
>===================================================================
>+MSG_INSTALLATION_PATH_WITHIN_WINDIR=Uninstall has detected that the installation path of $ProductNameInternal$ is installed to a folder within your Windows folder. Uninstall will not attempt to delete this installation due to the potential removal of critical system files.
We should just skip this message and not offer to delete the directory
at all in this case.
>+MSG_DELETE_INSTALLATION_PATH=Not all files were uninstalled from the installation path:\n\n %s\n\nDo you want to completely delete this folder?
Files not installed with $ProductNameInternal$ remain in the installation
directory %s
Do you want to completely delete this directory anyway?
Avoid mixing folder/path/directory terminology -- pick one and stick with it.
>+Cleanup On Upgrade=TRUE
You couldn't call this option "Nuke From Orbit Upgrade"?
Just kidding ;-)
>Index: wizard/windows/setup/dialogs.c
>===================================================================
>+LRESULT CALLBACK DlgProcUpgrade(HWND hDlg, UINT msg, WPARAM wParam, LONG lParam)
>+ GetPrivateProfileString("Strings", "Message Cleanup On Upgrade", "",
>+ buf, sizeof(buf), szFileIniConfig);
>+ ReplacePrivateProfileStrCR(buf);
>+ SetDlgItemText(hDlg, IDC_MESSAGE0, buf);
If you take my multi-line suggestion from the Usage section you could
get rid of RplacePrivateProfileStrCR() but you'd have write a new
GetMultilineMessage("Strings", "Message Cleanup On Upgrade", etc)
function.
>+ case WM_COMMAND:
>+ switch(LOWORD(wParam))
>+ {
>+ case IDDELETE:
>+ /* If the installation path happens to be within the %windir%, then
>+ * show error message and continue without removing the previous
>+ * installation path. */
>+ if(IsPathWithinWindir(sgProduct.szPath))
As mentioned before, Windir should be checked before you show the delete dlg.
>+ /* Prompt user if deleting target path is okay. Only show
>+ * prompt if the setup is running in normal mode, else
>+ * assume user wants deletion */
>+ if(sgProduct.mode == NORMAL)
>+ {
>+ hDlgCurrent = InstantiateDialog(hWndMain, dwWizardState,
>+ warningTitleString, DlgProcUpgrade);
>+ bDone = TRUE;
>+ }
>+ else
>+ sgProduct.doCleanupOnUpgrade = TRUE;
People running in !NORMAL mode don't get the benefit of the WINDIR check
and thus could end up deleting everything. I guess you're assuming that
no packager would be silly enough to make that the default, and if they
did they're smart enough to bury it down a few levels so this isn't a
problem. All right, I buy that.
>+ /* SiCNodeSetItemsSelected() is called from within DlgProcUpgrade().
>+ * If DlgProcUpgrade is not called (in the case of a !NORMAL install),
>+ * then we need to call it here. */
If the mode is NORMAL it appears there are two cases when
SiCNodeSetItemsSelected() gets skipped: if checkCleanupOnUpgrade
is false or no previous installation is found.
>Index: wizard/windows/setup/extra.c
>===================================================================
>+char *ExcludeRemoveList[] = {"plugins",
>+ "uninstall",
>+ "install_status.log",
>+ ""};
This list belongs in the config file.
>+BOOL IsPathWithinWindir(char *aTargetPath)
>+ if(strstr(targetPath, windir))
Couldn't you use strncmp() for the length of windir? If
targetPath is shorter then fine, if longer it needs to
start with windir not just have windir somewhere within it.
I guess you could change it to if(strstr(targetPath, windir)==targetPath)
if you prefer.
Attachment #126581 -
Flags: review?(dveditz) → review-
What's the status of the work on this bug? Drivers would like to see this in
1.5alpha, but there doesn't seem to have been any progress for quite a few days.
Assignee | ||
Comment 18•21 years ago
|
||
working on new patch now. stay tuned...
Assignee | ||
Comment 19•21 years ago
|
||
Filed bug 212244 to have ExcludeRemoveList moved to the config.ini file. No
time to do it right now.
Assignee | ||
Comment 20•21 years ago
|
||
Changed the strings on the buttons:
"&Delete" -> "&Continue" (default pushbutton now too)
"&Ignore" -> "&Skip"
"&Back" -> no change
Removed the dialog prompting the user if they really want to create the
directory chosen. It now just creates it.
Talked to dveditz and agreed to leave the "deleted installation dir is within
windir" prompt as is.
Changed Cleanup On Upgrade= strings.
>If the mode is NORMAL it appears there are two cases when
>SiCNodeSetItemsSelected() gets skipped: if checkCleanupOnUpgrade
>is false or no previous installation is found.
fixed.
>I guess you could change it to if(strstr(targetPath, windir)==targetPath)
>if you prefer.
changed.
>>+char *ExcludeRemoveList[] = {"plugins",
>>+ "uninstall",
>>+ "install_status.log",
>>+ ""};
>This list belongs in the config file.
filed as bug 212244
Attachment #126581 -
Attachment is obsolete: true
Comment 21•21 years ago
|
||
Comment on attachment 127411 [details] [diff] [review]
patch v1.1
r/sr=dveditz
Attachment #127411 -
Flags: review+
Attachment #127411 -
Flags: approval1.5a?
Assignee | ||
Comment 22•21 years ago
|
||
This patch (compared to v1.1) only adds a change that checks if the user
selected a directory within the windows dir. Nothing else done to it.
I rather we take this patch over v1.1, if possible. I've tested this change
too.
Assignee | ||
Comment 23•21 years ago
|
||
diff to show the trivial change between patches v1.1 and v1.2.
Comment 24•21 years ago
|
||
Comment on attachment 127435 [details] [diff] [review]
patch v1.2
sr=jag
Attachment #127435 -
Flags: superreview+
Assignee | ||
Comment 25•21 years ago
|
||
Comment on attachment 127435 [details] [diff] [review]
patch v1.2
moving r=dveditz to here
seeking a=
the patch is about moderate in the risk factor.
It does modify the dialog sequence logic because there's a new Cleanup dialog
now. However, this has been tested thoroughly and the sequence is working
nomally.
The actual cleanup code is trivial because it just looks for and verifies that
it's not in the list of ExludeRemoveList, then simply calls existing functions
to do the deletion.
This has tremendous gains in that it will prevent users from upgrading to a
broken mozilla (usually crash on startup) due to 3rd party files beyond the
installer's control.
Attachment #127435 -
Flags: review+
Attachment #127435 -
Flags: approval1.5a?
Attachment #127435 -
Flags: approval1.4.x?
Attachment #127411 -
Flags: approval1.5a?
Comment 26•21 years ago
|
||
OT
One very small question that isn't related to the topic of this bug. What, if
any, differance is there between Approval1.5a and Blocking1.5a, and I see this
bug has one set to "?" and the other set to "+"?
Attachment #127435 -
Flags: approval1.5a? → approval1.5a+
Assignee | ||
Comment 27•21 years ago
|
||
same patch as v1.2 except that it had some spelling errors fixed. This is the
exact patch that was checked in to trunk.
Attachment #127411 -
Attachment is obsolete: true
Attachment #127435 -
Attachment is obsolete: true
Attachment #127436 -
Attachment is obsolete: true
Assignee | ||
Comment 28•21 years ago
|
||
patch v1.2.1 checked in on the trunk only. Leaving bug open until patch lands
on branch.
Comment 29•21 years ago
|
||
Comment on attachment 127435 [details] [diff] [review]
patch v1.2
a=asa for checkin to the 1.4 branch (for this or v1.2.1, whichever is correct.)
Attachment #127435 -
Flags: approval1.4.x? → approval1.4.x+
Comment 30•21 years ago
|
||
Please note in the checkin that this affects the translation of Windows install
files.
Thanks
Assignee | ||
Comment 31•21 years ago
|
||
patch checked in to the MOZILLA_1_4_BRANCH on the mozilla tree now. In the ns
tree, only the files in xpinstall\packager\*.* were checked in.
Updated•21 years ago
|
Keywords: fixed1.4 → fixed1.4.1
Comment 32•21 years ago
|
||
*** Bug 200651 has been marked as a duplicate of this bug. ***
Comment 33•20 years ago
|
||
FYI: per comment 0: one additional file should've been added to the files that
don't need to be deleted from the target dir, and that's "mozilla.bmp".
Bug 248102 was opened for that.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•