Issue 49861

set target.

Looks like it is on purpose. Download template
setup_native/source/win32/nsis/downloadtemplate.nsi contains:

Section -Post

IfSilent onPostSilent onPostNoSilent

onPostSilent:
        ExecWait "$INSTDIR\setup.exe -lang $LANGUAGE /qr -ignore_running"
        RMDir /r $INSTDIR
        RMDir $INSTDIR
GoTo onPostDone

onPostNoSilent:
        Exec "$INSTDIR\setup.exe -lang $LANGUAGE"
        Quit
GoTo onPostDone

onPostDone:

SectionEnd

And we are probably in "NoSilent". Why? Shouldn't we add

        RMDir /r $INSTDIR
        RMDir $INSTDIR

to both branches? Or should we change to "Silent"?

of @ mh: I don't think it makes sense to remove the installation source after
unpacking. The setup modify and repair option needs these files and will fail if
they are removed. Therfore I would consider it as a bug to remove these files.

IIUC it is as follows:

- if you want to run setup.exe manually something wrong hapenned and there is
big probablility that it doesn't happen right after the successfull installation
of OOo (only after successfull installation the unpacked directory is to be removed)

- you do not have a chance to run setup.exe with different parameters from NSIS
installer

- right now, after finishing the installation, all people have to manually
remove the directory where NSIS unpacked the source for the installation

Q: Is it possible to run setup.exe with "setup modify or repair options"
directly from the NSIS archive the same way as the correct installation is called?

I'll answer to myself. I have just tried running NSIS installer again after
complete successfull installation and removing the folder with installation
files completely. NSIS installer started and I'm now offered with the following
possibilities:

- Modify
- Repair
- Delete

(translated from cs back to en-US, so please try to imagine that dialog :-)

So it looks like it is completely OK to remove the files (even after
unsuccessfull installation), because setup.exe is intellingent enough.

of: Maybe you were describing all this with not having NSIS in your mind? I do
not want to remove OpenOffice.org_....exe file, but the folder with installation
files (in my case, it was unpacked to Desktop).

If you start the modify or repair option from the control panel 'Ad Remove
Software' you've lost. The installer can't find the .msi file and fails. 

I do not use Windows at all, so my question might look funny to you: is it
typical to copy DVD with the installation to the disk, install from there and
*not* remove the copied installation files?

If I understand you, you are writing that we have to leave the installation
files on the disk too?

In fact, yes, after removing the folder with unpacked installation files, I
can't finish the installation's repair or modify. I have to run the setup/repair
again from the NSIS .exe file.

If the user installs from CD he usually knows that he has to insert the CD to
continue with the installation. While the setup is running with a (re)moved
installation source you'll get a messagebox the xyz.msi can't be found. The you
can point to the msi file (if it has moved). If you have the nsis file only, you
can't point anywhere to proceed.

of: so in addition to install ~210MB on the disk, we will also ask user to keep
81MB directory somewhere?

They'll kill us...

I understand your technical reasons to leave them where they are, but I do not
think people will follow the rule to leave files on the disk. I predict that 99%
of all users will remove that directory after finishing the installation.

This report was create on the feedback of one such user (not me ;-).

If users do it they do it on their own risk. At least it makes more sense to
remove the nsis file after unpacking just as it has been with the zip file
before. And in times of 80GB harddisks.....

Hmm, interesting question....
The windows installers usually do not store the full installer pack on the
users's system. But if you use an msi based installer, it may require the
availability of installation package.
If you want to add/modify/and sometimes remove the setup of OOo it may require
the unpacked installation set. So option without deleting is would be nice. But
the mass of users will remove that unpacked install set. In onther hand if you
start the distribution package it will start the setup again and ask for option
(modify/repair/delete).
The best solution would be if the users can make the dicision about deleting of
unpacked file.
You can review my way regarding this question:
http://qa.openoffice.org/issues/show_bug.cgi?id=51780
Executable example:
http://www.openoffice.org/nonav/issues/showattachment.cgi/27825/OOo_1.9.106-en-US.zip
Hey,
KAMI

Another solution is to add command line interface. It does not require new ui
strings. For example if we specify /remove options for the installer it will
remove the unpacked installation package...
AFAIU the current situation is when you specify:
/S runs the installer or uninstaller silently. See section 4.12 for more information
switch the pre-installer will remove the unpacked files.
One note:
The lines:
RMDir /r $INSTDIR
RMDir $INSTDIR
is very very dangerous. That is why it step forward to InnoSetup (and for
another hundred reason). If you add a system like folder as extraction path it
will delete them all... We should avoid this type of attack :o)

kami_: command line options are useless for typical user. He will simply click
on the exe file. Nothing else. We have to solve the situation for such user, not
for users who can run that installer from command line...

Adding Ingo to CC:.

We have discussed this problem when we introduced the nsis installer.  And it is
true. For the Windows Installer the installation set is stored in that
directory, where nsis unpacked it. Therefore this installation set cannot be
removed because of the maintenance mode.
But this is not the CD problem. The nsis installation sets shall not be located
on a CD. There we use the installation sets without nsis. And in this case in
maintenance mode the CD is required. 
The nsis is only used for downloads. And in this cases the user has no CD and
threrefore needs to have the installation sets for the maintenance mode on his
harddisk. 

Ingo: I think the decision was wrong.

I think much better way would be:

- disable Change/Repair in the Add or Remove Programs dialog *or* create simple
app to be called and display "Please run Repair/Modify option from the
installation set."

- remove unpacked installation files after NSIS is finished

But as I already said: I'm no Windows expert. Only my logic tells me that
installing 80+210 MB instead of 210MB is not the best solution. And the only
reason being critial case of corrupted installation and the fact that the
installation can be Reapired/Modified from the new run of NSIS .exe file.

Volker: what is your opinion?

Greetings from Zion National Park, Utah :-)

> But as I already said: I'm no Windows expert. Only my logic tells me that
> installing 80+210 MB instead of 210MB is not the best solution.
Yes, but it's "only" 33% more. We could warn the user and say something like:
"You can remove the unpacked installation files <put directory here> and gain
80 MB of harddisk space but you will lose the ability to select Change/Repair."
at the end of the NSIS installation.

> And the only
> reason being critial case of corrupted installation and the fact that the
> installation can be Reapired/Modified from the new run of NSIS .exe file.
              can't ?

Yes, that is unfortunate.

I really don't care that much about the extra harddisk space and I think the
majority of users will not download the nsis package but install the release
version from some CDs/DVDs that inevitably will be found in computer magazines.

pjanik: 
You wrote Tue Aug 2 03:42:51 -0700 2005:
- you do not have a chance to run setup.exe with different parameters from NSIS
installer

I don't know if this is what you meant but command line parameters can be passed
from e.g. nsis.exe -p to setup.exe -p by using a premade function:
http://nsis.sourceforge.net/wiki/Get_command_line_parameters

Example available in the script in issue 4729.

change target to OOoLater.

I still think that repair can be done by downloading the same NSIS .exe file
again from the Internet (aka "inserting the CD back").

I think that 'You want to repair you office but you can't because of NSIS has 
deleted your files so download again the whole stuff and sorry if you only have 
a modem?' isn't a solution. I don't think that we should delete these unpacked 
files. Forcing someone to redownload is a mess and not offering a repair or 
modify also.

andreschnabel->pjanik:
all your concerns about wasting diskspace is easy to resolve, esp. when
installing from disk: don't use NSIS package. Put the plain (unzipped) msi
Installer on the disk and be happy. 

We can prevent most of the problems named here, when making NSIS not the default:
- no need to remove temporary install files
- no need to write special commandline interface
- easy reinstall / repair from original setup or windows control panel.


But .. for the current issue: If you provide NSIS and don't want to leave setup
files after installation, just make it optional and tell the user what they
might be usefull for.

I think the best way to handle the issue for 2.0 would be:

1. unpack to temp folder
2. install by calling setup
3. change 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PRODUCTC
ODE\ModifyPath to nsis installer exe
4. delete temp folder

Step 3 should be implemented inside downloadtemplate.nsi (I've never used NSIS 
but I'm sure it's possible) 

If some user selects AppWiz's modify/repair option then the downloaded nsis 
installer gets called offering all possibilities.

Location:

IF we really have to use NSIS, and the directory is really unmovable/undeletable,
then please put it somewhere else, NOT on the Desktop.
It can be in the /Windows folder, or newly created /Program Files/OpenOffice.org/setup 
or anything that is NOT the Desktop.

Q: Why ?
A: Periodically, Windows XP will ask the user to clear out unused icons (documents/folders) on the 
Desktop (or eventually it automatically do that for the user) -- so the path will broken.
(and this is a worst case scenario, Wasted disk space AND Cannot repair the setup -- at the same time!)

*** Issue 56747 has been marked as a duplicate of this issue. ***

What about to put Installation files into defaultly a folder under root drive
like this:
C:\Installation Files\OpenOffice.org<version>

Pros: It easy to locate it under Windows, Not dependent on one user's profile,
MOS2003 do the same thing

But we have to create the way to remove those files after the installation in
the Preinstaller.

The easiest way to locate a folder is to place it on the desktop. If the user
thinks that "?:\Installation Files\OpenOffice.org<version>" will be better he
has the chance to change it.

OK, I must agree :o)

Please keep in mind that for distribution software on a Windows network, getting
access to the plain MSI files is *A MUST*. Anything else is just a pain in the ass.

Looking at the fact that we currently don't have a transformation wizard for
OOo, but only for SO8 (on the enterprise CD), network installation doesn't make
much fun at the moment. But if getting the plain MSIs will get harder (i.e.
running installer and then getting the MSIs out of the temp directory), this is
no option.

At least, please offer a ZIP download so one could get the MSI packages.

*** Issue 62883 has been marked as a duplicate of this issue. ***

I opened an issue about this in issue 62883 (now marked a duplicate), but then I
was pointed to this issue. I will therefore post comments here.

If I may add some comments from a user's point of view:

-To a user, I would guess that the "repair" thing is not their first thought.
(It wasn't mine.) The first thought is, "why didn't OOo delete these files? We
don't need them anymore."
-In other words, unzipping the files on the Desktop and then leaving them there
looks to the user like OOo didn't clean up after itself. Users like me are
likely to delete the files themselves to free up space. Then, the "repair"
option won't work AND it is a nusaince to the user to have to delete the
installation files manually.
-Unzipping the files elsewhere hides them from the user and is acceptable. But
this can still start to use up drive space quickly if the user keeps installing
new versions of OOo. This is especially true for QA volunteers who install the
next release every couple of weeks. 80 MB is not a lot of space, but 80*10 = 800
MB is a full CD's worth. As a QA volunteer, I can easily accumulate that much
space used in 4 months of OOo development releases. Maybe a solution would be to
have the installer remove previous installation files? Maybe it already does
this? I always delete them myself, so I don't know, but it seems like if the
installation files might be anywhere, the installer wouldn't know where to
delete old installation files from.
-If repair is a concern, can OOo ask up-front where OOo itself will be installed
(not just where the installation files will be unzipped), then unzip the
installation files to a subdirectory of the target directory? Then the
installation files are always available for repair and always in a standard
location. Also, the user does not have to get the unsightly files off his/her
desktop.
-For example, first screen shows "Where would you like to install OpenOffice?"
and has a target "C:\Program Files\OpenOffice.org\". Then, the installer unzips
to "C:\Program Files\OpenOffice.org\Repair\" and runs setup from there. Setup
then installs to "C:\Program Files\OpenOffice.org\" automatically, without
asking the user a second time where the program should be installed. I am not a
programmer, so I don't know how feasable this is to do. But it would be nice for
the end user to not have to worry about it.
-Alternatively, you could just make it optional for the user to delete the files
after installation. For an visual representation of this, see my attachment to
issue 62883.

Steve

We should even think about deleting the compressed download file. This is
useless after uncompressing it and can be removed.

what is the probability of the user needing to use the "repair"? This behaviour
is looking very unprofessional (what users see is, OpenOffice is leaving
temporary files around, and even worse, on their desktop). And in the extremely
unlikely situation that the installation would need a repair, 99% of people
wouldn't know that they have a repair option in the add/remove programs (and
then there is the question of the probability of the repair option to work).

And I'm expecting to see many computers with folders "OpenOffice 1.0
installation files" "OpenOffice 1.1 installation files" "OpenOffice 2.0
installation files" "OpenOffice 2.1 installation files", and so on. These are
"system files" that users won't dare to delete "it might break something" and
will stay there forever. Which means, this is wasting much more than 33% of disk
space, and much more than 80Mb.

In any case, of programs with downloadable installers on the internet, I think
OpenOffice is absolutely the only one with this policy. firefox not, opera not,
thunderbird not, winzip, inkscape, gaim, filezilla, blender, etc etc etc... not.
I'm not sure about Acrobat reader though.

I think at the very least the installer needs a checkbox "Keep installer files
on disk for repair option (uses 80Mb)".
But if the user downloaded the file from internet the first time (even using
dialup), it's not shocking to ask them to do it again in the extremely unlikely
case that they'd need the repair option.
In the real world, dialup users will get OO from a CD and it won't be a problem
for them to reinstall it, and users with a fast connection won't have a problem
reinstalling.

*** Issue 76237 has been marked as a duplicate of this issue. ***

@ emmanuel_t:
I think at the very least the installer needs a checkbox "Keep installer files
on disk for repair option (uses 80Mb)".

THis can be a good movement. Let's the user decide what he really want.

*** Issue 85113 has been marked as a duplicate of this issue. ***

> I think at the very least the installer needs a checkbox "Keep installer files
> on disk for repair option (uses 80Mb)".

I agree with this sentiment, but I strongly recommend NOT to place those
installer files on the desktop, or indeed anywhere else the user might perceive
as intrusive. The correct place for these files is the program directory because
these files pertain to the program and nothing else on the system.

These filed *do not* belong to the program so they don't have to be placed in
the program folder. These files belong to the installation. This is *not* the
same. Where else then the Desktop to place these files? Nothing is more
intuitive than the Desktop. And as said, the user can change the path while
extracting. And a 'self destroying' function for an installer I've never seen.
For me it's a lot of noise about a minor problem.

*** Issue 85113 has been marked as a duplicate of this issue. ***

of: I'm sure I'm repeating something that has already been said : 

1) Why an installed inside another installer? 
NSIS is a very versatile and powerfull installer, it could perform the entire
process. 
Windows installer could also work out of a single self extracting archive. 

Again, why an installer that just unpackes another installer? 
- to increase the duration of the installation process
- to use up double the disk space then the initially downloaded installer
- to leave almost 100MB of files somewhere on the disk (user's desktop)
- hassle the user to manually delete a bunch of installation leftovers

something installed with MSI also copies parts of the kit as a MSI file
somewhere inside c:\windows for it's Modify/Repair feature, why can't OO
(assuming this is an issue) do the same, instead of leaving the entire kit on
the desktop? and besides, leaving it on the desktop is like asking for the user
to manually remove it, then any modify/repair functionality won't work any way! 

besides, it's not that much of an effort to uninstall it completely and put it
back in. and with the fairly frequent version updates, what the hell would I
need a repair option? Just install the latest one, or the initial one, whose kit
I saved somewhere... 
user's prefs are savedin homedir, right? so a reinstall cycle won't affect the user.

I've seen (fortunately only a few) uninstallers that requested the original
instalation kit (usually the cd) for it to perform just uninstall (forget the
modify/repair this time) and IMO I felt such a combination to be the worst
possible idea.

is -> andrixnet: Please do not mix up different things. For the problem, that we
have to keep the installation set on the system, it is not important, if we use
a wrapper around the installation set or not. For the OpenOffice.org
installation we use the Windows Installer service, nothing else, and this will
surely not be changed in the near future.
To simplify the download mechanism we introduced a wrapper by using nsis. We
could also use a simple zip or a selfextracting exe or whatever. This would
change nothing to this problem. After the Windows Installer installation set is
successfully unpacked on your system, it is started from this position on your
system. And exactly this position is important for the maintenance mode like
repair or adding components (for removing components or the complete product the
installation set is not required). You could for example first install Writer
and Calc and later decide that you also want to use Impress and Draw. For such a
scenario you need the source files again. And Windows Installer "knows" where to
find it, because it saved the location of the original installation set. 
The CD scenario you mention ("please insert the CD") works for OOo fine, but of
course you have to install OOo from the CD, not from your local hard drive. So
you simply have to use a CD containing OpenOffice.org or you have to download
it, use the nsis wrapper only for unpacking and burn the installation set on a
CD. Then you could start the installation from CD and if you later want to
repair the installation or add components, Windows Installer would tell you
"Please insert the CD."
But in our scenario the Windows Installer "knows" that OOo was installed from
<somewhere_on_your_local_hard_drive>. If we remove the installation set after
the first successful installation, this must lead to an error in maintenance
mode, because the Windows Installer knows that the installation set is no longer
available. In this error dialog you can select a new path to the installation
set.  So if you burned it on CD before removing it, you can now also use the CD.
But this is surely not what we want.
If you say, that "Repair" is not so important, well okay, we could discuss about
it. But I think, that adding components is not so unusual. So I think, that we
are not allowed to remove "Change installation" in maintenance mode.
But to stress it again. This has nothing to do with nsis or any other wrapper we
could use to simplify the download. Even if we include all cabinet files into
the msi database and use a one file Windows Installer installation set without
any wrapper: You have to start the installation from your local hard drive and
the installation set has to be saved exactly at this place.

I have about 50 different pieces of software installed on my PC. Can you imagine
my desktop if every program did what you guys are doing?

The desktop is MINE and I really hate programs leaving their stuff there without
my permission. What makes OO _particularly_ bad is that unlike shortcuts, I
can't just delete or move the files without breaking some dependencies. Another
reason not to leave YOUR setup files on MY desktop.

In corporate environments the desktop is often stored in the roaming profile.
The roaming profile disk space quotas can be fairly restrictive. Another reason
why this is a bad default.

MS Office leaves the setup files on the PC as well. Where are they? I don't know
and I couldn't care less. I'm sure 99% other users don't care either. They are
not on the desktop, they do not interfere. By leaving them on the desktop you
REQUIRE the users to care. Leave them somewhere if you have to but not on the
user's own private personal space!

(MS Office installer is also kind enough to tell you that it's left X megabytes
of files which it could delete for you immediately if you don't want them.)

SUGGESTIONS:
1. Offer the user an option to delete the files at the end of the install process.
2. Store them _wherever_ you want OTHER THAN my Desktop and My Documents.
C:/Windows/$MyProgramsInstaller$ seems to be a common place for these things.

quote: "I really hate programs leaving their stuff there without my permission"

Actually you gave OO permissions to use your desktop. The installer offers the
option to unpack wherever you want. 

But -agreed there should be an option to remove the files after successfull
installation (but this was mentioned previously here). Making the same claims
again and again doesn't help at all.

CCing IS

I just enable in cws native133 usage of modern nsis versions, like nsis 2.3.5.
And I also like the suggestion in task i66883, to add a checkbox to the
directory selection dialog, in which the user is asked to remove the
installation set at the end of the installation. Can anybody make a patch, in
which the checkbox is added to the existing directory selection dialog?

Ah, I mean i62883, not i66883.

Having a checkbox is nice, but does not really fix the problem.  If removing the
installation files breaks something else, then this practice should be
discouraged--or at least the user should be warned about the ramifications of
such a choice.  Providing the option is a great idea, but the default location
still needs to be somewhere other than the desktop.

I regularly use Windows 2000, XP, Fedora, Ubuntu, and--less frequently--Solaris.
 I don't recall ever seeing any program other than OOo using the desktop as the
default location for the installation files.  What I do see frequently under
Windows is the option to change installation directories--along with a warning
recommending that you keep the defaults.  I have learned the hard way that
changing the defaults often results in problems when it comes time to upgrade,
repair, or uninstall.  Consequently I (and I suspect most users) hesitate to
change the default directory settings during installation.

But here's some numbers.  I found 218 .msi files on my Windows XP laptop:
  74 under C:\dell\Drivers
  11 under C:\Documents and Settings (only 7 unique files)
   2 under C:\i386
  11 under C:\Program Files
 120 under C:\WINDOWS

A further breakdown of that last 120:
   4 under C:\WINDOWS\Downloaded Installations
   2 under C:\WINDOWS\Hewlett-Packard\Setup Files
 107 under C:\WINDOWS\Installer
   5 under C:\WINDOWS\Microsoft.NET
   2 under C:\WINDOWS\System32

Of the 11 under C:\Documents and Settings, 5 of them are duplicates--one in each
user's directory, plus one under Default User.  So there are really only 7
unique .msi files under C:\Documents and Settings.  (OOo did not come up in this
list since I naturally deleted the installation directory.)

Most are under C:\WINDOWS.  But there is clearly a precedence for using
C:\Program Files.  Using C:\Program Files also makes it clear at a glance what
program the installation files go with.  An alternative would be to follow the
HP example and utilize C:\WINDOWS\OpenOffice.org\Setup Files (or something similar).

I know that OOo is a professional quality product.  However, sticking with the
Desktop as the default installation directory makes OOo seem very unprofessional
and makes it very HARD to "sell".  It gives a bad first impression to users,
system administrators, and others who are considering migrating to OOo.

Hi!
I hope I can provide patch, if we decide what we want. I suggest to create such
checkbox?
[x] Keep installation files after the installation

For location:
If install as administrator we can put it to:
C:\WINDOWS\Downloaded Installations

As a simple user we should keep these files in the users profile.

Another point of view:

We can alway put the installtion files to:
C:\OpenOffice.org.install\[version] folder for example

I should have noted that the 11 installation files under C:\Documents and
Settings were under either username\Local Settings or username\Application Data.
 (None were on the Desktop.)

With the default installation of recent versions of Windows (XP and later), I
believe you have to be a computer administrator in order to install programs, so
I don't believe we have to worry about simple users doing an installation.  That
is, assuming default folder protections and such haven't been modified, then if
the user has access to install a program under the Program Files folder, then he
has access to save the installation files anywhere!  (A possible exception might
be installing a user profile to access an existing network installation--but
that's not really installing OOo.)

*** Issue 91689 has been marked as a duplicate of this issue. ***

My own 3c. 

1c) I consider leaving a folder full of install files on the desktop absolutely
AWFUL. I don't care what the reason. If they must be left (which I find highly
questionable, see 2c) at least put them somewhere out of the way, not in My
Documents and certainly NOT on the Desktop. Let me say it again. AWFUL.

2c) Repair? I have not yet encountered a single Windows user who was even aware
that there is a 'repair' option, ever. Let alone used it. If any installed
program becomes broken they all simply run the installer again from the CD or
wherever. And in the unlikely case that some user expects a repair option and
can't find one, I'm sure running the installer again would be the next most
obvious action. 

3c) Having an installer within an installer on the CD seems totally pointless,
and adds a big long delay which causes most users to assume the CD didn't
autorun and go looking for it in My Computer, and then get twice as annoyed when
two installers pop up because they manually ran a second one when the first was
quietly loading itself into ram. I've been remastering the CD image before I
give it to people so that it simply runs the 'real' installer from the
beginning. No delay. No messy folder on the desktop. If they need to repair they
can just put the CD back in. If they ever have to repair, it's probably time to
upgrade to the next version anyhow.

@ zcat: 
1c) Everyone has the chance to change the location where these file should be
stored.
2c) If you haven't encountered that anybody uses this function doesn't mean that
nobody uses it. It's a common feature that the Microsoft Installer offers.
Rerunning the setup doesn't make a difference because it will also offer the
repair. But that will also not be possible if the installation files are deleted.
Following your suggestion the user has to uninstall and reinstall his Office.
*That* is a bad user experience.
3c) Is a different problem for different project that should be addressed in a
new issue. It's not an installation problem but a distribution issue.

Got a lot of feedback that after downloading OOo start's it installation process
again and again. It seems to be bad user experience that after first
installation there is a new "something" on the desktop which does not the
expected thing. We really should remove this behavior therefor I set target 3.1
for this issue.

I also see not the need to create a backup of the installation files, either the
user can store this by his own action separately or get it again from the
original medium (CD, Internet). 

reassign to UX for final say.

Please also do think of poor admins who need their MSI files and leave an option
to extract all files from the setup EXE to a directory, like

setup.exe /extract:c:\filestore\ooo31

There are already many existing options in the download installation sets, like
only unpacking or remove after unpacking, or unpack into dir xyz, or ... .
Please have a look at this parameters using

setup.exe /HELP=ON

seems noone has done anything - change target

*** Issue 104605 has been marked as a duplicate of this issue. ***