40708 - Mozilla installer should not install files into a subfolder

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P4)

Description

[Sean Su]

The mozilla installer for windows should not install Seamonkey into a subfolder 
from where the user chooses to install it.  It should install into what the user 
has chosen as the destination path.

This is essentially undoing the following bug:
  http://bugzilla.mozilla.org/show_bug.cgi?id=39783

but only for Mozilla installers, not N6.  The fix is a simple 3 line change in 
Mozilla installer's config.ini.  This will not affect the N6 installer.

I copied the relavent comments from bug #39783 below:

**** Additional Comments From Gervase Markham 2000-05-26 01:32 ****

I'm reopening this bug, because this new behaviour breaks my nicely organised QA 
system. I posted in n.p.m.builds about this, and was directed here.

Here follows my post, explaining why the old behaviour was useful:

<snip>
I've been working on Mozilla for several months now, and have built up a
collection of builds I use for tracking down regressions, and
reproducing old bugs. They are in my C:\Program Files\Mozilla\2000-XX-XX
directories. There is also a C:\Program Files\Mozilla\Users50 directory
which contains a profile which they all share. This is very useful, as
it means I can delete my profile and *.dat using a batch file, whenever
I want (for testing reasons) without having to worry about "which"
profile I'm deleting, because they all share one, and it's always in the
same place.

This was made possible by the fact that, up until the 22nd of this
month, if I told the installer to put Mozilla in "C:\Program
Files\Mozilla\2000-XX-XX", that's exactly where it put it. It also put
the Users50 directory at the same level as 2000-XX-XX.

Now, it seems to have been changed so that it doesn't put it where I ask
it to any more, but in a subdirectory of the one I request called
"Seamonkey", at the same level as a Users50 of its very own. This
obviously breaks the above very useful facility, and also means the
installer doesn't do what I tell it to, which is generally a bad thing.

Can anyone explain why the behaviour was changed? And can we please
change it back? :-)
<snip>

It seems what you are saying is that you are changing this behaviour to deal 
with clueless lusers (on Windows only) who accidentally install in C:\, then 
install a new version - the current installer would detect the old 
C:\netscp6.exe and nuke the entirety of C:\. I admit this is bad.

But why must everyone else have to put up with the installer not doing what is 
expected because a few people (on Windows) are so stupid? Surely we just need to 
cope with this one special case by making a subdirectory if the root is chosen 
as the install directory.

If Netscape wish to add this "feature" to their development tree, that's their 
business - it's their tree :-) But Mozilla is targeted at _developers_, and this 
change in functionality is _not_ required and also inconvenient for QA people 
like me who keep multiple builds.

Please consider changing it back, or having it as an installer config pref (off 
for Mozilla) or _something_.

<jumps up and down and tears out hair>

Gerv



**** Additional Comments From Simon Lucy 2000-05-26 02:12 ****

Surely the fix is to detect installations that would be in stupid places and 
warn before deleting anything, adding superfluous levels of sub-directories is 
just irritating.  

All that needs to be done is to check for the path not ending in ':' or ':\' 
and if it does append something suitable, not 'Netscape 6' though, using 
embedded spaces in file systems even when the user understands them is asking 
for trouble.  



**** Additional Comments From Henrik Gemal 2000-05-26 04:23 ****

I agree 150%, it's insane!

The uninstaller should uninstall the files installed by the installer and 
nuthing else!

An advanced feature could be that the uninstaller asked the user to delete the 
entire installation directory after deleting the known installed files 
(http://bugzilla.mozilla.org/show_bug.cgi?id=40544)



**** Additional Comments From Gervase Markham 2000-05-26 06:04 ****

[e-mail] - please could you back out the changes from this bug, and keep 
them in hand for applying to the nb2b tree, after the branch? That would be 
fantastic :-)

Gerv

Comment 1

[Gervase Markham [:gerv]]

[e-mail] - thank you very much for filing this bug :-) But I'm unsure as 
to what happens now - are you going to be fixing this, or do we have to find 
someone to do it?

In addition, lxr tells me that there is not a "config.ini" file in the Windows 
installer. However, I found mozilla/xpinstall/packager/windows/config.it, which 
has:

18            Sub Path=Seamonkey

which seems like a good candidate for removal, or turning to ""... Is it this 
simple? You said a "three" line change...

Anyway, enough of my musings.

Gerv

Comment 2

[Sean Su]

Henrik,

This is not necessarily an uninstaller issue.  This problem is with how to 
upgrade users to a new build.  The correct method is to figure out all the 
files/directories all the previous installers ever created and only hand pluck 
them.  This will eliminate the problem of deleting c:\ and any other files the 
users copied into the Seamonkey folder.

Normally, the installer could simply run the previous installation's 
uninstaller, then continue the installation.  However, the uninstaller was 
just recently added to the installer.  Running the uninstaller to remove the old 
files do not work for the builds that did not have an uninstaller.

The correct method could not be applied at this time due to time constraints, so 
a intermediate solution needed to be in place, which is to warn the user that a 
deletion of the entire Seamonkey folder is necessary, or chose a different 
installation path.

In any case.  I don't agree that we should install directly to the folder the 
user (whether a developer or a newbie) choses.  I see it as keeping our 
installation directory selection simple and clean by installing into a subfolder 
of the chosen folder (in addition to preventing a disaster).

I could detect for ":\" given the example I provided in the bug, but that 
doesn't take into account any other "unintended" paths the user 
happens to chose by accident (whatever they could be by anyone's definition).

The fix to revert the original fix is simple, but not necessarily the right 
thing to do.

Gervase,

Reverting the fix to alleviate a QA process is not a good enough reason for me.  
The fix was done to deal with a serious problem.

However, there are things that could be done to work with your QA process, like:
** renaming the ...\mozilla\Seamonkey dir before running the installer
** copying the users50 dir to the new ...\mozilla dir
** setup an automation system to modify config.ini in the installer so that it 
will do exactly what you want it to do before you start the installation.

I can help you with the last option.

Comment 3

[Samir Gehani]

OK, so this bug is worksforme then, right?

Comment 4

[Gervase Markham [:gerv]]

> The fix was done to deal with a serious problem.

I partly understand the need for the fix where clueless users are involved; 
however, Mozilla is a product for _developers_, who aren't clueless. This is why 
I suggested the fix be backed out, and made to a Netscape 6-specific tree. A 
clueful person such as a developer will expect software to be installed where 
they ask for it to be installed. 

As for your other suggestions, I'm not sure I understand. I download pre-built 
nightlies for smoketesting (and other QA things) on a regular basis. Are you 
saying I can in some way "poke" that copy of mozilla-win32-installer.exe before 
I run it so that it will Do The Right Thing?

Regarding for your comments to Henrik, I'm not quite clear there either. Are you 
saying that the final solution to this problem will be to run the old version's 
uninstaller, and the new behaviour I don't like is merely a temporary thing?

[ Samir - not yet, we are still discussing this issue ;-) ]

Gerv

Comment 5

[Sean Su]

Gervase, I can help you automate a process that will let you modify how the 
installer behaves, then launch setup.exe.

It sounds to me like you're doing the installation by hand right now.  There are 
parameters you can currently pass to the installer that can make things easier:
  -ma :Mode Auto - runs the installer in a hands free mode (showing only non
       interactive dialogs) using all defaults from its config.ini.
  -ms :Mode Silent - runs the installer in a silent mode (not showing *any*
       dialogs) using all defaults from its config.ini.

The problem now is how to change the defaults in the config.ini file to your 
liking.  What I'm going to do is to add a new parameter so that the 
self-extracting .exe file can simply uncompress its contents into the current 
directory without launching setup.exe.  This way you can modify the config.ini 
(I can help you with this one too) so it'll install exactly the way you want it, 
then launch setup.exe when you're done.

I have the fix on hand to the self-extracting code.  It's reviewed and tested, 
but I still need approval before I can checkin.

The new parameter is (will be):
  -u :uncompress - this will simply tell the self-extracting .exe file to
      uncompress its contents into the current working directory and do
      nothing else.

Comment 6

[Gervase Markham [:gerv]]

Right... I am currently doing installs by hand, but that's because each install 
has to go into a different directory depending on its build ID. One can't always 
work this out from the current date, as I sometimes install older builds, and 
it's not part of the filename either.

So, the plan would be to write a Perl script to do:
C:\> mozinstall 2000-XX-XX

cd \temp
C:\download\mozilla-win32-installer.exe -u
<munge config.ini using command line param>
C:\temp\setup.exe -ma

?

Would -u do a hands-free overwrite "clobber"?

I do appreciate your help, but would still prefer the old way ;-). Just as a 
side note, please don't think that the dialog I've started in the newsgroups 
(about checking in "novice user" changes into the Moz tree) is getting at you, 
because it isn't.

Gerv

Comment 7

[Daniel Veditz [:dveditz]]

I think we should start a discussion on this in n.p.m.xpinstall -- not many 
will stumble accross this bug. Once started we can forward the post to 
[e-mail] to get a little more visibility.

Could someone with ready access to Henrik's e-mail CC him on this bug -- he was 
quoted in the other bug and may not be following this one.

Comment 8

[Gervase Markham [:gerv]]

dveditz: Would you please start the discussion on n.p.m.xpinstall?

CCing Henrik.

Gerv

Comment 9

[Ben Bucksch (:BenB)]

I completely agree with Gervase. Do exactly what I say. When I ran Windows, I
had a perfectly layed out file system. I actually used the application dirs to
some extend, so this behaviour required me to open one more folder.

Bug 40865 is related.

Comment 10

[Sean Su]

The -u parameter has been added to the self-extracting code.  Automation 
instructions have been send to Gerv.

Marking this bug fixed.

Grace, here's the test case:
1) download NetscapeSetup.exe or mozilla-win32-installer.exe into a save folder.
2) from the save folder, run the .exe file from the command line and pass in -u:
  NetscapeSetup.exe -u

it should uncompress its contents into the directory you ran the .exe from.

Comment 11

[Ben Bucksch (:BenB)]

I don't think, this is the correct way to fix this. I don't want this bug been
fixed, because of a testing problem, but because it creates an unnecessary
hierarchy level for users. REOPENing.

When bug 6464 is fixed, "SeaMonkey" will be the only child of the install dir.
This is silly.

Please find a better way around the "uninstalling all of C:" problem. How do
other apps solve this? Mozilla is no exception here.

Comment 12

[Gervase Markham [:gerv]]

Ben - if you want something different done, you need to explain why Mozilla 
should not continue with the practice of Communicator. That is to say, 
Communicator installs like this:

Give it: C:\Program Files\Netscape
It installs in: C:\Program Files\Netscape\Program and C:\Program 
Files\Netscape\Users

Mozilla currently installs like this:

Give it: C:\Program Files\Mozilla
It installs in: C:\Program Files\Mozilla\Seamonkey and C:\Program 
Files\Mozilla\Users50

These seem to be exactly analogous.

Gerv

Comment 13

[Ben Bucksch (:BenB)]

Gerv, as I said, Users50 will go, leaving "SeaMonkey" alone. Anyway,
Communicator is not a perfect application either.

Comment 14

[Simon Lucy]

The main fault is in deleting the entire content of the installed directory.  
It doesn't matter what directory an application is installed into, any 
uninstall or re-install should only mess with files the application itself 
creates.

Blowing away random files is just wrong.  

Comment 15

[Daniel Veditz [:dveditz]]

Adding selmer and racham because they were asking about this behavior

Comment 16

[Gervase Markham [:gerv]]

I'm now happy (following some help from Sean Su) so I'm removing myself from the 
CC list :-)

Gerv

Comment 17

[Daniel Veditz [:dveditz]]

I think the depends on is a mistake, or at least I can't remember why I 
connected these two bugs.

Comment 18

[Ben Bucksch (:BenB)]

dveditz: The subfolder critizised in this bug was a workaround for bug 31821, to
avoid overwriting an existing installation, IIRC. Readding dep.

Comment 19

[Henrik Gemal]

*** Bug 67025 has been marked as a duplicate of this bug. ***

Comment 20

[Peter Lairo]

Another reason this is important is that once the path gets to be too long,
there are reported errors associated with it (forgot the bug#).

It is the first time i used the installer, as opposed to the
mozilla-win32-talkback.zip file, and like the smaller footprint and java
installer. Nevertheless, the user should have the final say as to where his
programs are installed to.

Adding an unwanted and unneeded directory is just annoying - clueless lusers
will just have to learn how to use a PC, that's it. Why suject the normal
majority of users to unwanted subdirectories?

Why don't you just disable the delete key while you're at it!  :(

Comment 21

[Sean Su]

*** Bug 67185 has been marked as a duplicate of this bug. ***

Comment 22

[Sean Su]

Attachment: patch #1 (ns tree)

Comment 23

[Sean Su]

Attachment: patch #1 (moz tree)

Comment 24

[Daniel Veditz [:dveditz]]

r=dveditz

Comment 25

[Sean Su]

Attachment: patch #2 (with comments)

Comment 26

[Sean Su]

Attachment: patch #2 (moz tree - with comments)

Comment 27

[Daniel Veditz [:dveditz]]

r=dveditz for second patch set 

Comment 28

[Peter Lairo]

this is a terrible habbit to have programs create a company name directory and
then sneak in the product name beneath it. My hard drive is no place for
companies to advertize. I want the program name to be my directory and I want
control over what directories my programs are installed to.

The proposed pathes sneak in a directory name that the user is not being told
about. This practice should ceise right now!

Comment 29

[Sean Su]

The patches should do exactly what you wanted to have the installer do in the
first place.

I'm not sure why you think the patch will be "sneaking" in a directory name and
the user not being notified about it.  The patch will essentially make visible
the currently hidden subdirectory that gets created, namely the "Mozilla"
subdirectory.  This will allow the user to change the final folder name.

What the installer used to show and create:
  shows  : [Program Files]\Mozilla.org
  creates: [Program Files]\Mozilla.org\Mozilla

What it will do after the patch is applied:
  shows  : [Program Files]\Mozilla.org\Mozilla
  creates: [Program Files]\Mozilla.org\Mozilla
  (the user can change the entire path now)

As for having installers create default folders of:
  [Program Files]\[Company Name]\[Product Name]

it is the norm in a Windows environment to do so (according to the Windows setup
guidelines).  It makes more sense this way because the [Company Name] could have
more than one [Product Name], in which case the folders would look like:
  [Program Files]\[Company Name]\[Product1 Name]
  [Program Files]\[Company Name]\[Product2 Name]
  [Program Files]\[Company Name]\[Product2 Name]
  and so on...

Comment 30

[Ben Bucksch (:BenB)]

> it is the norm in a Windows environment to do so (according to the Windows
> setup guidelines).

Really? I never liked that. I like [Program Files]\[Company
Name][SPACE][Product1 Name]. In other words, IMO, the windows guide is broken.

> It makes more sense this way because the [Company Name] could have
> more than one [Product Name]

Yes, but that case is very uncommon (unless you count Microsoft). At least for
me, it is the expection that I install 2 software packages from the same company
at the same machine (/ OS installation). Which means that most directories in
[PROGRAMFILES] have exactly one child, unless I prevent that manually. *That*
doesn't make sense to me. I'd prefer an uncommon
  [Program Files]\[Company Name] [Product1 Name]
  [Program Files]\[Company Name] [Product2 Name]
but I'll probably forsee that and manually adjust the path in the installer in
this case.

So, I vote for "Path=[PROGRAMFILESDIR]\$CompanyName$ $ProductName$"

> creates: [Program Files]\Mozilla.org\Mozilla

Bug 67238.

Comment 31

[Ben Bucksch (:BenB)]

s/expection/exeption/

Comment 32

[Scott MacGregor]

sr=mscott for patch #1 (ns tree) and the 1/31/01 10:57 patch 2

Comment 33

[Henrik Gemal]

I really like:
[Program Files]\Mozilla.org\Mozilla

this is also the normal windows way to do it.

Comment 34

[Peter Lairo]

Users don't think of their programs in terms of company names but rather in trms
of the program's name they are using. The idea of having the company name as the
main program directory is ludicrous and was thought out by marketing executives
and not programmers interested in the user's way of thinking.

For application suites that all use common files - isn't that what the
windows\application direstory is for? - although i do think that the rule should
apply: one program -> one directory.

Also, the installer is currently so narrow, that the whole path is currently not
visible - this is annoying. The window with should be at least wide enough to
show the full default path plus 50% in case a user chooses a longer directory
tree. Better would be to show the full path as tooltip when hovered over, or to
wrap the tree onto multiple lines.

Comment 35

[Sean Su]

patches checked in.  Marking this bug fixed.

Comment 36

[Daniel Veditz [:dveditz]]

Peter: two separate issues here. If you don't like the default install path 
drum up support in the newsgroups, and if the [e-mail] folks tell us 
to change it we will. As you can see from the patch it's now just a single 
string in a non-compiled text file.

Your UI ideas about the field too narrow and the tooltips are good 
user-experience feedback; we'll keep that in mind. It is, however, off-topic in 
this particular bug.

Comment 37

[Grace Bush]

sub folders not present - build 2001020204 of both Mozilla and N6 Installers