httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@awe.com>
Subject Re: 1.3.4 win32 installer problems
Date Tue, 16 Feb 1999 12:08:41 GMT
On Sat, 13 Feb 1999, Marc Slemko wrote:
> so does anyone have a handle on why, on various systems for various
> reasons (unfortunately, it appears that far too many win32 problem
> reporters have the "it doesn't work, fix it.  Tell you the details of what
> system I am using?  No, it doesn't work.  Fix it." attitude), the
> installer sometimes doesn't install the conf files, etc.?

Um, there doesn't seem to be much of a pattern the the PRs:

3900 Win95
3800 Win98
3850 Win NT4 SP3
3827 NT4
3741 Win95a
3740 Win 4.00.1381

Just in case it isn't clear, what happens during the install is this:

 - The IS installer installs all the files. This would overwrite
   conf/*.conf, so the installer puts configurable files into
   .tmp. It also puts the index.html from htdocs here, so we don't
   clobber the user's configured htdocs/index.html, if they have one.

 - Then IS calls a function in the INSTALL.DLL file. This function
   does the configuration:

     - move .tmp/*.conf, magic and mime.types to conf/*.default, 
       expanding @@ServerRoot@@
     - for each *.default file, copy to *.conf _IFF_ that
       file does not exist already
     - move .tmp/index.html to htdocs/index.html _IFF_ that file
       does not exist. If it does exist, silently delete .tmp/index.html
     - remove the .tmp directory (which should be empty).
     - return an OK status to IS

 - If the DLL returned OK, exit. Otherwise IS will display a warning.

Now all the respondents say that "conf" is empty. That seems to indicate
that the INSTALL.DLL function isn't being run (if it was run but found an
error, it *should* exit with an error code and IS should warn the user).

So without much additional help from the submitters, I guess what we can
do is get INSTALL.DLL to write log of what it is doing, so we can see
at the least if it is being called and if so, how far it is getting
before something goes wrong. I'm doing this now.

Also as a diagnostic tool, there is a program in
win32/installer/installdll/test which calls INSTALL.DLL as if it was being
run from the installer (this is how INSTALL.DLL can be tested during
development). However this uses a fixed path and isn't user friendly. So
we could update this program to be something that a user could run, if the
install failed.

Paul


Mime
View raw message