Обсуждение: PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install

I cannot install PostgreSQL 9.0 (x86-64) under Windows 7 (x86-64). The
installer fails right after starting the installation process with the
message:

"An error occurred executing the Microsoft VC++ runtime installer".

I am using the installer from EnterpriseDB
http://www.enterprisedb.com/products/pgdownload.do. Installation file
is postgresql-9.0.0-1-windows_x64.exe.

Unfortunately there is no %TEMP%\install-postgresql.log.

When scanning the mailing lists under
http://www.postgresql.org/community/lists/ and under
http://forums.enterprisedb.com/forums/show/9.page I can see that this
error has been described for several times with PostgreSQL 8.3 and 8.4
under different Windows variants. A common hint was to activate the
Windos Scripting Host (WSH) allthough it obviously does not help in
all cases. On my machine the WSH is activated and working.

Under
http://www.enterprisedb.com/learning/pginst_guide.do#troubleshooting
you can read about the command line options of the EnterpriseDB
PostgreSQL Installer. An attempt with "--install_runtimes 0" fails again
but with the different error message:

"Unknown error while running C:\Users\Administrator\Lokale
Einstellungen\postgres_installer\getlocales.exe"

Again there is no %TEMP%\install-postgresql.log.

As the second message is suggesting I am working as local
Administrator while installing PostgreSQL.

Maybe it is worth to be mentioned that I have installed Microsoft
Visual Studio 2008 Pro DE. Therefore the installation of the VC++
runtime should not be neccessary.

I am using now MySQL for serveral years and would like to compare it
with a current PostgreSQL version. The installation of PostgreSQL
under Windows is really disappointing but the same worked without
problems under Linux x86-64 (openSUSE 11.0). Under Linux I have used
the EnterpriseDB Installer of PostgreSQL 9.0 (x86-64) as well. The
installation file is postgresql-9.0.0-1-linux-x64.bin.

Is this problem already known and is there a solution for it?

Hi Peter,

We tried to reproduce this issue but could not do so. We have tried both the cases but both were not reproducible. Can you please provide more information which can help us in reproducing the issue,

Thanks,
Dharmendra



--
Dharmendra Goyal
Senior Software Engineer
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +91-20-30589493
Mobile: +91-9552103323

Website: http://www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.

Hi Dharmendra,

thanks for your reply. This kind of errors, which cannot be reproduced
on other machines are bad and leave no chance for developers to solve
them.

Unfortunately the installer does not leave any log files. The Windows
event log has no entries about the installation attempt as well.

I do not know what further information could be helpful. My first idea
was that my installed MS Visual Studio 2008 could be the
problem. Therefore I tried the "--install_runtimes 0" option -
unfortunately with no success. My Visual Studio installation works as
expected. I conclude it from various projects which all built fine.

I am running a Windows 7 x86-64 for about 3 months and it runs without
problems. I cleanly installed the system onto an empty, e.g. formated
harddrive.

As the first described error
"An error occurred executing the Microsoft VC++ runtime installer"
has been discussed with previous releases of PostgreSQL, e.g.
http://forums.enterprisedb.com/posts/list/2328.page
I think that it is a known issue. Moreover, exactly the same error has
been described in the EnterpriseDB forum under
http://forums.enterprisedb.com/posts/list/2303.page
with PostgreSQL 9.0 and Windows 7 x86-64. However, both posts remain
un-replied until today.

If there are no other users out there with comparable problems I could
give the ZIP-installer a try under:
http://www.enterprisedb.com/products/pgbindownload.do
There is a file postgresql-9.0.0-1-windows_x64-binaries.zip. I did not
yet try this because I am new to PostgreSQL. I first have to figure

- how to start the database from the command line,
- how to setup the PostgreSQL service from the command line,
- what registry entries are required.

If you can answer the above three questions (each with one sentence),
I will immediately start installation and tests, because I hope - from
my short but good PostgreSQL 9.0 experiences under Linux - that just
the installer fails on my system but not the database system itself.

If you need any other information that might help, please let me
know. I would really like to get some more knowledge about
PostgreSQL.

Regards,
Peter

On Thu, Sep 30, 2010 at 1:42 PM, Dr. Peter Voigt <pvoigt@uos.de> wrote:
> Hi Dharmendra,
>
> thanks for your reply. This kind of errors, which cannot be reproduced
> on other machines are bad and leave no chance for developers to solve
> them.
>
> Unfortunately the installer does not leave any log files.

Please look for any logfiles in %TEMP% starting with "bitrock".


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

Dave Page <dpage@pgadmin.org> writes:

> On Thu, Sep 30, 2010 at 1:42 PM, Dr. Peter Voigt <pvoigt@uos.de> wrote:
>> Hi Dharmendra,
>>
>> thanks for your reply. This kind of errors, which cannot be reproduced
>> on other machines are bad and leave no chance for developers to solve
>> them.
>>
>> Unfortunately the installer does not leave any log files.
>
> Please look for any logfiles in %TEMP% starting with "bitrock".

Well, the installer does not leave any file starting with "bitrock" in
my %TEMP% directory. I am using the default %TEMP% value as created
during system installation. Its value is (German operating system)
"C:\Users\Administrator\Lokale Einstellungen\Temp" or in 8.3 notation
"C:\Users\ADMINI~1\LOKALE~1\Temp". The subdir "Lokale Einstellungen"
is a link to "C:\Users\Administrator\AppData\Local":

Administrator@TIGER2008:C:\Users\Administrator> dir /a |grep -i lokale
28.08.2010  15:22    <VERBINDUNG>   Lokale Einstellungen [C:\Users\Administrator
\AppData\Local]

However, a scan of my whole system partition reveales a file "bitrock.log"
under C:\Users\Administrator\AppData\Local. I have just re-created it
with a fresh installation attempt. Please find it attached.

I have tried to interpret the error in the log. The installer
complains about not finding file
"C:\Users\Administrator\Lokale Einstellungen\postgresql_installer\installruntimes.vbs".

I suppose it is important for you to know that this file
"installruntimes.vbs" is present - but under
"C:\Users\Administrator\AppData\Local". This is the same directory
where I finally found the log.

On Thu, Sep 30, 2010 at 7:41 PM, Dr. Peter Voigt <pvoigt@uos.de> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>
>> On Thu, Sep 30, 2010 at 1:42 PM, Dr. Peter Voigt <pvoigt@uos.de> wrote:
>>> Hi Dharmendra,
>>>
>>> thanks for your reply. This kind of errors, which cannot be reproduced
>>> on other machines are bad and leave no chance for developers to solve
>>> them.
>>>
>>> Unfortunately the installer does not leave any log files.
>>
>> Please look for any logfiles in %TEMP% starting with "bitrock".
>
> Well, the installer does not leave any file starting with "bitrock" in
> my %TEMP% directory. I am using the default %TEMP% value as created
> during system installation. Its value is (German operating system)
> "C:\Users\Administrator\Lokale Einstellungen\Temp" or in 8.3 notation
> "C:\Users\ADMINI~1\LOKALE~1\Temp". The subdir "Lokale Einstellungen"
> is a link to "C:\Users\Administrator\AppData\Local":
>
> Administrator@TIGER2008:C:\Users\Administrator> dir /a |grep -i lokale
> 28.08.2010  15:22    <VERBINDUNG>   Lokale Einstellungen [C:\Users\Administrator
> \AppData\Local]
>
> However, a scan of my whole system partition reveales a file "bitrock.log"
> under C:\Users\Administrator\AppData\Local. I have just re-created it
> with a fresh installation attempt. Please find it attached.
>
> I have tried to interpret the error in the log. The installer
> complains about not finding file
> "C:\Users\Administrator\Lokale Einstellungen\postgresql_installer\installruntimes.vbs".
>
> I suppose it is important for you to know that this file
> "installruntimes.vbs" is present - but under
> "C:\Users\Administrator\AppData\Local". This is the same directory
> where I finally found the log.

Thats very odd, but it explains why things are going wrong -
essentially, the prerequisites are being unpacked to:

C:\Users\Administrator\AppData\Local

But the installer expects to find them in:

C:\Users\Administrator\Lokale Einstellungen\

Which is a link to the first folder. I (as the guy the wrote the
original version of the installer) expect them to be in:

C:\Users\Administrator\Lokale Einstellungen\Temp\

So, it sounds like there are two questions for me to figure out - why
is the installer not able to follow the link and find the files (which
is probably a question for BitRock), and why isn't it using the actual
Temp subdirectory as it's supposed to.

A couple of questions for you Peter (and thanks for bearing with us
while we figure this out):

- How are you running the installer? Are you logged in as
"Administrator", or are you using "Run As Administrator" or something
similar?

- What's the output from the "SET" command when run in the same user
environment as the installer (ie. from an Administrator command
prompt, or one launched however you've escalated your privileges).

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

Dave Page <dpage@pgadmin.org> writes:

> A couple of questions for you Peter (and thanks for bearing with us
> while we figure this out):
>
> - How are you running the installer? Are you logged in as
> "Administrator", or are you using "Run As Administrator" or something
> similar?

I am logged in as "Administrator" when running the installer.

>
> - What's the output from the "SET" command when run in the same user
> environment as the installer (ie. from an Administrator command
> prompt, or one launched however you've escalated your privileges).

Please find the environment of user "Administrator" attached:

ACR_BIN=C:\Program Files (x86)\Adobe\Reader 9.0\Reader
ALLUSERSPROFILE=C:\ProgramData
APACHE2_HOME=C:\Program Files\Apache Group\Apache22
APACHESRC=C:\Programme\Apache Group\Apache22
APPDATA=C:\Users\Administrator\AppData\Roaming
asl.log=Destination=file;OnFirstLog=command,environment,parent
BIBINPUTS=D:\home\pvoigt\tex\texsty
BSTINPUTS=D:\home\pvoigt\tex\texsty
CATALINA_HOME=C:\Program Files\tomcat60

CLASSPATH=.;C:\Programme\mysql-connector-java-5.1.10\mysql-connector-java-5.1.10-bin.jar;C:\Programme\sqljdbc_1.1_deu\sqljdbc.jar;C:\Program
Files\tomcat60\lib\servlet-api.jar;d:\home\pvoigt\java\vog-libs\VogSystem.jar;d:\home\pvoigt\java\vog-libs\VogIO.jar;d:\home\pvoigt\java\vog-libs\MyIO.jar;d:\home\pvoigt\java\vog-libs\VogDbUtil.jar;d:\home\pvoigt\java\vog-libs\VogTime.jar
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=TIGER2008
ComSpec=C:\Windows\system32\cmd.exe
CURL_CA_BUNDLE=D:\temp\ca-bundle.crt
EASY_INSTALL_BIN=C:\Programme\Python26\Scripts
EDITOR=C:\Program Files\vim\vim73\gvim.exe
EMACS_OPTS=-geometry 80x45 --reverse-video
FOP_HOME=C:\Program Files\fop
FP_NO_HOST_CHECK=NO
FRD_BIN=D:\local\bin
FTPROOT=E:\srv\ftp
GNUPGHOME=D:\home\pvoigt\.gnupg
GNUWIN32_BIN=D:\local\GnuWin32\bin
GSV_BIN=C:\Program Files\ghostgum\gsview
GS_BIN=C:\Program Files\gs\gs8.64\bin
GS_LIB=C:\Program Files\gs\gs8.64\lib;C:\Program Files\gs\fonts
HEISE=D:\home\pvoigt\ct-ix\inhalt.frm
HOME=D:\home\pvoigt
HOMEDIR=D:\home\pvoigt\.gnupg
HOMEDRIVE=C:
HOMEPATH=\Users\Administrator
INFODIR=D:\local\Emacs\emacs\info;D:\local\Emacs\emacs\site-info
INFOPATH=D:\local\Emacs\emacs\info;D:\local\Emacs\emacs\site-info
JAVA_HOME=C:\Program Files\Java\jdk
KLEOPATRA_LOGDIR=D:\home\pvoigt\.gnupg\kleopatra
LANG=DE
LESS=-I -N -M -S
LOCALAPPDATA=C:\Users\Administrator\AppData\Local
LOCAL_BIN=D:\local\bin
LOGONSERVER=\\TIGER2008
LYNX_CFG=C:\Program Files (x86)\Lynx\lynx.cfg
LYNX_LSS=C:\Program Files (x86)\Lynx\lynx.lss
MIKTEX_BIN=D:\local\MiKTeX\miktex\bin
MINGW_HOME=D:\local\MinGW
MSYS_HOME=D:\local\msys\1.0
MYSQL_JDBC_HOME=C:\Program Files\mysql-connector-java-5.1.10
NUMBER_OF_PROCESSORS=2
OPENSSL=C:\Program Files (x86)\openssl
OPENSSL_CONF=D:\home\pvoigt\certs\ca\my_openssl.config
OPENSSL_INC=C:\Program Files (x86)\openssl\include
OPENSSL_LIB=C:\Program Files (x86)\openssl\lib
OS=Windows_NT
Os2LibPath=%Os2LibPath%
PAGER=D:/local/gnuwin32/bin/less.exe
Path=C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\PC Connectivity
Solution\;C:\ProgramFiles\ImageMagick;D:\local\MiKTeX\miktex\bin;c:\Program Files (x86)\NVIDIA
Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files(x86)\GNU\GnuPG\pub;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\Program Files
(x86)\QuickTime\QTSystem\;C:\ProgramFiles\Common Files\Microsoft Shared\Windows
Live;D:\local\tex4ht\bin\win32;D:\local\tex4ht\bin\ht\win32;C:\ProgramFiles
(x86)\openssl\bin;C:\Programme\gnutls\bin;d:\local\bin;d:\local\gnuwin32\bin;D:\home\pvoigt\ct-ix;C:\ProgramFiles
(x86)\Emacs\emacs\bin;C:\ProgramFiles (x86)\GNU\GnuPG;C:\Program Files\Java\jdk\bin;C:\Program
Files\Python27;C:\ProgramFiles\Python27\Scripts;C:\Program Files\vim\vim73;C:\Program Files\perl\bin;C:\Program Files
(x86)\lynx;C:\ProgramFiles (x86)\Adobe\Reader 9.0\Reader;C:\Program Files (x86)\php;D:\home\pvoigt\python;C:\Program
Files\ghostgum\gsview;C:\ProgramFiles\MySQL\MySQL Server 5.1\bin;C:\Program
Files\7-Zip;C:\Programme\Python26\Scripts;C:\ProgramFiles (x86)\wget;C:\Program Files (x86)\curl;C:\Program
Files\curl;C:\ProgramFiles\ant\bin;C:\Program Files (x86)\NTP\bin;C:\Program Files (x86)\Mozilla Firefox 
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 15 Stepping 11, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0f0b
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=Administrator@TIGER2008:$p$g
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
PYTHONPATH=D:\home\pvoigt\python
PYTHONSRC=C:\Program Files\Python26
PYTHONSTARTUP=D:\home\pvoigt\python_startup.py
QTJAVA=C:\Program Files (x86)\QuickTime\QTSystem\QTJava.zip
SESSIONNAME=Console
SSL_CERT_DIR=D:\home\pvoigt\certs;D:\home\pvoigt\certs\ca;D:\temp
SSL_CERT_FILE=D:\temp\ca-bundle.crt
SystemDrive=C:
SystemRoot=C:\Windows
T2H_HOME=D:\local\bin
TEMP=C:\Users\ADMINI~1\LOKALE~1\Temp
TEXINPUTS=D:\home\pvoigt\tex\texsty;D:\local\tex4ht\texmf\tex\generic\tex4ht
TMP=C:\Users\ADMINI~1\LOKALE~1\Temp
USERDOMAIN=tiger2008
USERNAME=Administrator
USERPROFILE=C:\Users\Administrator
VBOX_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\
VS90COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\
windir=C:\Windows
XALAN_HOME=C:\Program Files\xalan

For the benefit of the list, I've raised this issue with the people
who supply the installer technology, as I can't see any reason why our
code would get this wrong.

On Thu, Sep 30, 2010 at 9:53 PM, Dr. Peter Voigt <pvoigt@uos.de> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>
>> A couple of questions for you Peter (and thanks for bearing with us
>> while we figure this out):
>>
>> - How are you running the installer? Are you logged in as
>> "Administrator", or are you using "Run As Administrator" or something
>> similar?
>
> I am logged in as "Administrator" when running the installer.
>
>>
>> - What's the output from the "SET" command when run in the same user
>> environment as the installer (ie. from an Administrator command
>> prompt, or one launched however you've escalated your privileges).
>
> Please find the environment of user "Administrator" attached:
>
>
> ACR_BIN=C:\Program Files (x86)\Adobe\Reader 9.0\Reader
> ALLUSERSPROFILE=C:\ProgramData
> APACHE2_HOME=C:\Program Files\Apache Group\Apache22
> APACHESRC=C:\Programme\Apache Group\Apache22
> APPDATA=C:\Users\Administrator\AppData\Roaming
> asl.log=Destination=file;OnFirstLog=command,environment,parent
> BIBINPUTS=D:\home\pvoigt\tex\texsty
> BSTINPUTS=D:\home\pvoigt\tex\texsty
> CATALINA_HOME=C:\Program Files\tomcat60
>
CLASSPATH=.;C:\Programme\mysql-connector-java-5.1.10\mysql-connector-java-5.1.10-bin.jar;C:\Programme\sqljdbc_1.1_deu\sqljdbc.jar;C:\Program
Files\tomcat60\lib\servlet-api.jar;d:\home\pvoigt\java\vog-libs\VogSystem.jar;d:\home\pvoigt\java\vog-libs\VogIO.jar;d:\home\pvoigt\java\vog-libs\MyIO.jar;d:\home\pvoigt\java\vog-libs\VogDbUtil.jar;d:\home\pvoigt\java\vog-libs\VogTime.jar
> CommonProgramFiles=C:\Program Files\Common Files
> CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
> CommonProgramW6432=C:\Program Files\Common Files
> COMPUTERNAME=TIGER2008
> ComSpec=C:\Windows\system32\cmd.exe
> CURL_CA_BUNDLE=D:\temp\ca-bundle.crt
> EASY_INSTALL_BIN=C:\Programme\Python26\Scripts
> EDITOR=C:\Program Files\vim\vim73\gvim.exe
> EMACS_OPTS=-geometry 80x45 --reverse-video
> FOP_HOME=C:\Program Files\fop
> FP_NO_HOST_CHECK=NO
> FRD_BIN=D:\local\bin
> FTPROOT=E:\srv\ftp
> GNUPGHOME=D:\home\pvoigt\.gnupg
> GNUWIN32_BIN=D:\local\GnuWin32\bin
> GSV_BIN=C:\Program Files\ghostgum\gsview
> GS_BIN=C:\Program Files\gs\gs8.64\bin
> GS_LIB=C:\Program Files\gs\gs8.64\lib;C:\Program Files\gs\fonts
> HEISE=D:\home\pvoigt\ct-ix\inhalt.frm
> HOME=D:\home\pvoigt
> HOMEDIR=D:\home\pvoigt\.gnupg
> HOMEDRIVE=C:
> HOMEPATH=\Users\Administrator
> INFODIR=D:\local\Emacs\emacs\info;D:\local\Emacs\emacs\site-info
> INFOPATH=D:\local\Emacs\emacs\info;D:\local\Emacs\emacs\site-info
> JAVA_HOME=C:\Program Files\Java\jdk
> KLEOPATRA_LOGDIR=D:\home\pvoigt\.gnupg\kleopatra
> LANG=DE
> LESS=-I -N -M -S
> LOCALAPPDATA=C:\Users\Administrator\AppData\Local
> LOCAL_BIN=D:\local\bin
> LOGONSERVER=\\TIGER2008
> LYNX_CFG=C:\Program Files (x86)\Lynx\lynx.cfg
> LYNX_LSS=C:\Program Files (x86)\Lynx\lynx.lss
> MIKTEX_BIN=D:\local\MiKTeX\miktex\bin
> MINGW_HOME=D:\local\MinGW
> MSYS_HOME=D:\local\msys\1.0
> MYSQL_JDBC_HOME=C:\Program Files\mysql-connector-java-5.1.10
> NUMBER_OF_PROCESSORS=2
> OPENSSL=C:\Program Files (x86)\openssl
> OPENSSL_CONF=D:\home\pvoigt\certs\ca\my_openssl.config
> OPENSSL_INC=C:\Program Files (x86)\openssl\include
> OPENSSL_LIB=C:\Program Files (x86)\openssl\lib
> OS=Windows_NT
> Os2LibPath=%Os2LibPath%
> PAGER=D:/local/gnuwin32/bin/less.exe
> Path=C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\PC Connectivity
Solution\;C:\ProgramFiles\ImageMagick;D:\local\MiKTeX\miktex\bin;c:\Program Files (x86)\NVIDIA
Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files(x86)\GNU\GnuPG\pub;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\Program Files
(x86)\QuickTime\QTSystem\;C:\ProgramFiles\Common Files\Microsoft Shared\Windows
Live;D:\local\tex4ht\bin\win32;D:\local\tex4ht\bin\ht\win32;C:\ProgramFiles
(x86)\openssl\bin;C:\Programme\gnutls\bin;d:\local\bin;d:\local\gnuwin32\bin;D:\home\pvoigt\ct-ix;C:\ProgramFiles
(x86)\Emacs\emacs\bin;C:\ProgramFiles (x86)\GNU\GnuPG;C:\Program Files\Java\jdk\bin;C:\Program
Files\Python27;C:\ProgramFiles\Python27\Scripts;C:\Program Files\vim\vim73;C:\Program Files\perl\bin;C:\Program Files
(x86)\lynx;C:\ProgramFiles (x86)\Adobe\Reader 9.0\Reader;C:\Program Files (x86)\php;D:\home\pvoigt\python;C:\Program
Files\ghostgum\gsview;C:\ProgramFiles\MySQL\MySQL Server 5.1\bin;C:\Program
Files\7-Zip;C:\Programme\Python26\Scripts;C:\ProgramFiles (x86)\wget;C:\Program Files (x86)\curl;C:\Program
Files\curl;C:\ProgramFiles\ant\bin;C:\Program Files (x86)\NTP\bin;C:\Program Files (x86)\Mozilla Firefox 
> PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
> PROCESSOR_ARCHITECTURE=AMD64
> PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 15 Stepping 11, GenuineIntel
> PROCESSOR_LEVEL=6
> PROCESSOR_REVISION=0f0b
> ProgramData=C:\ProgramData
> ProgramFiles=C:\Program Files
> ProgramFiles(x86)=C:\Program Files (x86)
> ProgramW6432=C:\Program Files
> PROMPT=Administrator@TIGER2008:$p$g
> PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
> PUBLIC=C:\Users\Public
> PYTHONPATH=D:\home\pvoigt\python
> PYTHONSRC=C:\Program Files\Python26
> PYTHONSTARTUP=D:\home\pvoigt\python_startup.py
> QTJAVA=C:\Program Files (x86)\QuickTime\QTSystem\QTJava.zip
> SESSIONNAME=Console
> SSL_CERT_DIR=D:\home\pvoigt\certs;D:\home\pvoigt\certs\ca;D:\temp
> SSL_CERT_FILE=D:\temp\ca-bundle.crt
> SystemDrive=C:
> SystemRoot=C:\Windows
> T2H_HOME=D:\local\bin
> TEMP=C:\Users\ADMINI~1\LOKALE~1\Temp
> TEXINPUTS=D:\home\pvoigt\tex\texsty;D:\local\tex4ht\texmf\tex\generic\tex4ht
> TMP=C:\Users\ADMINI~1\LOKALE~1\Temp
> USERDOMAIN=tiger2008
> USERNAME=Administrator
> USERPROFILE=C:\Users\Administrator
> VBOX_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\
> VS90COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\
> windir=C:\Windows
> XALAN_HOME=C:\Program Files\xalan
>
>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

(This is the second time I send this, as the first message apparently did not make it)

Dr. Peter Voigt, 30.09.2010 14:42:
> If there are no other users out there with comparable problems I could
> give the ZIP-installer a try under:
> http://www.enterprisedb.com/products/pgbindownload.do
> There is a file postgresql-9.0.0-1-windows_x64-binaries.zip. I did not
> yet try this because I am new to PostgreSQL.

It's actually not that hard ;)

You first need to create a "datadirectory" using "initdb.exe"
http://www.postgresql.org/docs/current/static/app-initdb.html

Make sure the user account under which the server will be running has full (write) access to that directory.

For me it is enough to run
initdb" -D "/path/to/datadir" --lc-messages=English -U postgres E UTF8 -A md5

> - how to start the database from the command line,
Once the data directory has been created, simply use pg_ctl:

pg_ctl -D "/path/to/datadir" start
http://www.postgresql.org/docs/current/static/app-pg-ctl.html


> - how to setup the PostgreSQL service from the command line,
pg_ctl -D "/path/to/your/datadir" register
(see the above link to the manual)

> - what registry entries are required.
None.

> If you can answer the above three questions (each with one sentence),
> I will immediately start installation and tests, because I hope - from
> my short but good PostgreSQL 9.0 experiences under Linux - that just
> the installer fails on my system but not the database system itself.

I have put the above statements in some very simple batch files to be able to easily repeat these steps


Regards
Thomas

* Dave Page wrote:

> Thats very odd, but it explains why things are going wrong -
> essentially, the prerequisites are being unpacked to:
>
> C:\Users\Administrator\AppData\Local
>
> But the installer expects to find them in:
>
> C:\Users\Administrator\Lokale Einstellungen\
>
> Which is a link to the first folder. I (as the guy the wrote the
> original version of the installer) expect them to be in:
>
> C:\Users\Administrator\Lokale Einstellungen\Temp\
>
> So, it sounds like there are two questions for me to figure out - why
> is the installer not able to follow the link and find the files (which
> is probably a question for BitRock), and why isn't it using the actual
> Temp subdirectory as it's supposed to.

It can't follow the link because these links (actually, junctions) have
ACLs that deny FILE_READ_DATA, which means you cannot enumerate the
contents of the target directory through the link. See
<http://technet.microsoft.com/en-us/magazine/ee851567.aspx> for an
explanation of the ACLs.

The OP indicates in his reply to your message that his %TEMP% path is

    C:\Users\ADMINI~1\LOKALE~1\Temp

, which is using one of these junctions. This is definitely not the
default value set when the Administrator profile is created during
installation; that value would be

    C:\Users\Administrator\AppData\Local\Temp

. I would recommend to change the user environment variables (TEMP and
TMP) to the correct value and retry.

Of course, even if it works, this does not answer two questions:

1. How did TEMP end up with this value?

2. Why does the installer use the wrong directory?

There are two things I can think of with regard to 1. The more likely
one is that there is some logon script or group policy that applies to
the local Administrator account, which was written for XP clients and
therefore uses XP paths. The other idea is that his system may have been
upgraded from XP by way of Vista and somehow kept the old paths intact.

As for 2, I suspect that somewhere in the installer, it walks down the
path to the TEMP directory, and fails at the junction because it cannot
read the contents of its target directory.

--
Christian

On Fri, Oct 1, 2010 at 11:01 AM, Christian Ullrich <chris@chrullrich.net> wrote:
> * Dave Page wrote:
>
>> So, it sounds like there are two questions for me to figure out - why
>> is the installer not able to follow the link and find the files (which
>> is probably a question for BitRock), and why isn't it using the actual
>> Temp subdirectory as it's supposed to.
>
> It can't follow the link because these links (actually, junctions) have ACLs
> that deny FILE_READ_DATA, which means you cannot enumerate the contents of
> the target directory through the link. See
> <http://technet.microsoft.com/en-us/magazine/ee851567.aspx> for an
> explanation of the ACLs.

Interesting, thanks for the link.

> The OP indicates in his reply to your message that his %TEMP% path is
>
>        C:\Users\ADMINI~1\LOKALE~1\Temp
>
> , which is using one of these junctions. This is definitely not the default
> value set when the Administrator profile is created during installation;
> that value would be
>
>        C:\Users\Administrator\AppData\Local\Temp
>
> . I would recommend to change the user environment variables (TEMP and TMP)
> to the correct value and retry.

Agreed.

> Of course, even if it works, this does not answer two questions:
>
> 1. How did TEMP end up with this value?
>
> 2. Why does the installer use the wrong directory?
>
> There are two things I can think of with regard to 1. The more likely one is
> that there is some logon script or group policy that applies to the local
> Administrator account, which was written for XP clients and therefore uses
> XP paths. The other idea is that his system may have been upgraded from XP
> by way of Vista and somehow kept the old paths intact.

I would lean towards the former - the upgrade issue seems like
something Microsoft would have ensured works correctly, though it's
possible that a pre-upgrade installation might be in an unexpected
state.

> As for 2, I suspect that somewhere in the installer, it walks down the path
> to the TEMP directory, and fails at the junction because it cannot read the
> contents of its target directory.

I've asked BitRock to confirm or deny that.

I'm thinking we should add a pre-installation check to ensure we can
write to $TEMP, and execute what we've written. Will look into that...

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

On Fri, Oct 1, 2010 at 1:06 PM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> On 10/01/2010 06:30 PM, Dave Page wrote:
>
>>> As for 2, I suspect that somewhere in the installer, it walks down the
>>> path
>>> to the TEMP directory, and fails at the junction because it cannot read
>>> the
>>> contents of its target directory.
>>
>> I've asked BitRock to confirm or deny that.
>
> It should be pretty trivial to test with Process Monitor. As I don't think
> my (English) system will have that junction point, I'm not sure I can
> observe the results with junction points, but I can certainly see if the
> installer is trying to walk the path.
>
> [clickety click]
>
> Yes, the installer walks the path. For each directory it does:
>
>  FASTIO_NETWORK_QUERY_OPEN ("QueryOpen")
>  FASTIO_QUERY_INFORMATION  ("QueryOpenNetworkInformation")
>  IRP_MJ_DIRECTORY_CONTROL  ("QueryDirectory")
>
> (see the attached screenshot)
>
> IRP_MJ_DIRECTORY_CONTROL is documented in MSDN as:
> http://msdn.microsoft.com/en-us/library/ff548658(VS.85).aspx
>
> The rest, I have no idea about. I don't do Windows innards by choice.

You would think it would walk backwards in the event of an error
rather than the other way round. Anyway, BitRock should be able to
tell us, unless it's their underlying toolkit/language/SDK that's
doing it.

> I wonder why it's walking the path? Such things are rarely a good idea,
> unless you're trying to backtrack on an access denied error to find out at
> what level of a path you lost access.

Right :-) I really should read to the end before commenting.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

First of all: Thanks to all who contributed to this issue. There are
many helpful and interesting comments.

I am going to reply to Christian's first question: How did TEMP end up
with this value?

I have just scanned my installation protocol which says, that I made a
registry backup of the current user enviroment right after the basic
system installation. After that backup I restored the previously saved
Windows XP Pro x86 DE user environment. This step changed the TEMP
setting from its default value to "C:\Users\ADMINI~1\LOKALE~1\Temp"
(8.3 notation), which corresponds to

"C:\Users\Administrator\Lokale Einstellungen\Temp".

I unintentionally changed the TEMP variable from its default
setting. I should have checked whether the TEMP values has changed or
not - but I did not. Newertheless, I would not have expected any
problems from a changed TEMP setting even if it contains links.

From my backup of the original user environment
[HKEY_CURRENT_USER\Environment] I can reconstruct the default value of
TEMP:

TEMP=%USERPROFILE%\AppData\Local\Temp

which resolves to

TEMP=C:\Users\Administrator\AppData\Local\Temp

The default TEMP setting does not contain any links. As a link is
obviously causing the installer to fail, it will probably finish
without problems when using either the default TEMP setting or any
non-default setting that does not contain any links.

Before I am going to install with the default TEMP setting I am doing
the desired tests for the BitRock Support and wait for the answer.

I will keep the list informed about any new results.

Although I have not yet received any feedback from the BitRock
support, I have meanwhile done some further tests. Most important
result is that the installer finished flawlessly after I changed the
"TEMP" and "TMP" variables back to the default
"%USERPROFILE%\AppData\Local\Temp".

I am interested to hear how the installer is intended to handle links
under Windows, because a link might also be contained within a
non-default installation path.

On Thu, Oct 7, 2010 at 9:43 AM, Dr. Peter Voigt <pvoigt@uos.de> wrote:
> Although I have not yet received any feedback from the BitRock
> support,

I closed the ticket with them - we know what the problem was in your
case, and we have enough info to try to put some additional checks in
the installer to prevent it biting people in future releases (or at
least give a more useful error message).

> I have meanwhile done some further tests. Most important
> result is that the installer finished flawlessly after I changed the
> "TEMP" and "TMP" variables back to the default
> "%USERPROFILE%\AppData\Local\Temp".

Thats good to hear.

> I am interested to hear how the installer is intended to handle links
> under Windows, because a link might also be contained within a
> non-default installation path.

It does handle the links OK, it's just that those particular ones have
an unusual ACL on them which caused our pre-installation actions to go
haywire. If such a problem occurs with the installation path, you
should get a regular "permission denied" error.

Regards, Dave.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company