Sorry for the delay - it's been a busy morning.
The Windows 7 system I'm using is a laptop with a standard basic Nokia
image. To the best of my knowledge there have been no OEM
modifications of any kind. It describes itself as "Windows 7
Enterprise", and says it is 32-bit. That's it.
Anything else you'd want me to check?
Karl
On Mon, Oct 3, 2011 at 4:11 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri@gmail.com> wrote:
>>> I saw a thread where somebody saw icacls.exe being called by the
>>> one-click installer. I'm having the same thing - the installer has
>>> been running for 45 minutes now and is basically going to have to be
>>> stopped because I'm out of time waiting for it. Looking at process
>>> monitor, it is clear that icacls.exe is going through every file on
>>> the entire system and changing its permissions. The process tree
>>> indicates that it is a child of the installer, and that it is running
>>> the command:
>>>
>>> icacls C:\ /grant "kawright":RX
>>>
>>> Clearly this won't do at all and should be considered a severe installer bug.
>>
>> If it does, it certainly sounds like a very bad bug.
>>
>> However, according to the documentation for icacls
>> (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you
>> should use "/t" to get it to traverse into subdirectories, and clearly
>> it's not doing that. So I wonder why it would go across the whole
>> filesystem - might tbere be a bug in icacls?
>
> Yes - that's how it's supposed to work (ie. *not* using /t). The
> purpose of that code is to ensure that the entire path leading up to
> the data/installation directories is readable by the users that need
> it. We've had a number of reported installation failures in the past
> caused by weirdness where read or execute permissions weren't
> available for (for example) the service account user, which caused
> somewhat mysterious failures.
>
>> Or maybe it has something to do with inheritance? The way
>> inheritance-permissions works on ntfs is, um, let's call it
>> interesting. Maybe it needs to specify the (NP) flag to not propagate
>> inheritance or something?
>
> Sachin/Ashesh; can one of you investigate this please?
>
> Karl; can you please provide precise details of your Windows version,
> and anything unusual about your disk configuration? I know this
> doesn't happen on any of the installations of Windows 7 that we use
> for testing (which tend to be the MSDN builds, running on local NTFS
> disks), so I wonder if there's an icacls bug in a specific build or
> rev of Windows, or when used on a certain type of filesystem.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
