Re: 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

> From: Dr. Peter Voigt <pvoigt(at)uos(dot)de>
> Date: Tue, Sep 28, 2010 at 11:53 PM
> Subject: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) -
> Unable to install
> To: pgsql-general(at)postgresql(dot)org
>
>
> 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?
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
>
>
>

--
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(at)uos(dot)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(at)pgadmin(dot)org> writes:

> On Thu, Sep 30, 2010 at 1:42 PM, Dr. Peter Voigt <pvoigt(at)uos(dot)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(at)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(at)uos(dot)de> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>
>> On Thu, Sep 30, 2010 at 1:42 PM, Dr. Peter Voigt <pvoigt(at)uos(dot)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(at)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(at)pgadmin(dot)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:

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(at)uos(dot)de> wrote:
> Dave Page <dpage(at)pgadmin(dot)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:\Program Files\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:\Program Files\Common Files\Microsoft Shared\Windows Live;D:\local\tex4ht\bin\win32;D:\local\tex4ht\bin\ht\win32;C:\Program Files (x86)\openssl\bin;C:\Programme\gnutls\bin;d:\local\bin;d:\local\gnuwin32\bin;D:\home\pvoigt\ct-ix;C:\Program Files (x86)\Emacs\emacs\bin;C:\Program Files (x86)\GNU\GnuPG;C:\Program Files\Java\jdk\bin;C:\Program Files\Python27;C:\Program Files\Python27\Scripts;C:\Program Files\vim\vim73;C:\Program Files\perl\bin;C:\Program Files (x86)\lynx;C:\Program Files (x86)\Adobe\Reader 9.0\Reader;C:\Program Files (x86)\php;D:\home\pvoigt\python;C:\Program Files\ghostgum\gsview;C:\Program Files\MySQL\MySQL Server 5.1\bin;C:\Program Files\7-Zip;C:\Programme\Python26\Scripts;C:\Program Files (x86)\wget;C:\Program Files (x86)\curl;C:\Program Files\curl;C:\Program Files\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(at)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(at)chrullrich(dot)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(at)postnewspapers(dot)com(dot)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(at)uos(dot)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