Thread: BUG #18707: Installation issue

The following bug has been logged on the website:

Bug reference:      18707
Logged by:          Gursh Panesar
Email address:      gursharan.panesar@bnpparibas.com
PostgreSQL version: 15.8
Operating system:   Windows 10
Description:

We have an issue installing version 15.8 using file
postgresql-15.8-1-windows-x64.exe.
The installation in our environment is run in the system context.
When the installation is run in the system context it writes to
C:\Windows\Temp folder and fails.
If the installation is run as admin, it writes to %LocalAppData%\Temp.
The previous version of the installer was able to run in system context and
install the application without any issue.

Each time the installation is run in system context, it generates a folder
with a different name so we cannot change the permission. If the temp folder
can have a fixed name, then it may be possible to change the permissions.

On Tue, Nov 19, 2024 at 12:06 AM Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
> Thanks for sharing the installation log. Could you once try installing postgresql-15.8-2-windows-x64.exe as I see a
commitin the Git around that bug? 

I wonder why the log shows "entr‚e" (instead of "entrée") in one
place, but apparently OK encoding elsewhere...  makes me pretty
suspicious of the account name "autorite nt\système", and I see there
is also an open issue in the github about "nt-autorität\system".  Just
a wild guess: would it help to use numerical SIDs instead of account
names when invoking shell commands like icacls?

On Tue, Nov 19, 2024 at 8:02 PM Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
> On Tue, Nov 19, 2024 at 6:39 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>> a wild guess: would it help to use numerical SIDs instead of account
>> names when invoking shell commands like icacls?
>
> Yes, I tried that recently. It works well for init cluster, but pg_ctl fails to register the service:

I suppose the SID-vs-username thing is just one case anyway, and even
if we taught pg_ctl -U to accept SIDs (looks doable), I bet you could
have the same problem with paths with funky characters in them.

Let's see... so you pass shell commands to DoCmd[1] which injects them
into a wrapper batch file, after setting the codepage to match the
ACP[2].  After reading lots of horrible details on the internet, that
looks like the right idea to me, as it means that the rest of the
batch file should match what the Visual Basic program is using when it
writes out the command line, instead of the old MS-DOS OEM codepage
assumed by cmd.exe batch files.  I assume that is working OK for
some/most people and must have worked OK for some non-ASCII stuff on
some configurations as that's why you added it, many years ago.  So
what is different in these cases?

Idea: could the Visual Basic program actually be using a different
ACP, not the one in the registry, due to some explicit locale setting
or environment variable somewhere?  Would it be better to call
GetACP() instead of that registry lookup[2]?

Some assumptions: I think VBA works entirely with wchar_t strings, and
I think objBatchFile.WriteLine must be the point of implicit
transcoding to char if the file wasn't opened in "Unicode mode"
(Unicode here meaning wchar_t, which sounds potentially useful for
sidestepping all this stuff but apparently it wouldn't work for batch
files), and surely that transcoding is done with the value from
GetACP().  I couldn't find where that is written down, though.

[1]
https://github.com/EnterpriseDB/edb-installers/blob/5721b7804676fe1b74f5a4287692f56bd52e8b8f/server/scripts/windows/initcluster.vbs#L173
[2]
https://github.com/EnterpriseDB/edb-installers/blob/5721b7804676fe1b74f5a4287692f56bd52e8b8f/server/scripts/windows/initcluster.vbs#L75

On Wed, Nov 20, 2024 at 12:15 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Idea: could the Visual Basic program actually be using a different
> ACP, not the one in the registry, due to some explicit locale setting
> or environment variable somewhere?  Would it be better to call
> GetACP() instead of that registry lookup[2]?

Guessing harder, in more actionable form: something like
LANG="fr-FR.UTF-8" might be enough to break your script, if VB itself
or something in your VB code calls setlocale(LC_ALL, "").  I have no
idea if it does, but if so, that could change the ACP for the process,
I think.  Perhaps Gursharan might like to check whether LANG or any of
the LC_ is set in the environment where the installer runs, and if so
whether the value implies a codepage that doesn't match
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP.
If so, just as an experiment, changing the variable to something with
a matching codepage (I think for example "fr-FR" without suffix
implies 1252, traditional encoding used for French) might work, just
to confirm what's happening, or kill this theory :-)  And if that's
it, and if GetACP() is the solution, then: the intergoogles told me
that you should be able to 'Declare Function GetACP Lib "kernel32" ()
As Long' to access it.