Re: [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe

I see no evidence that SP1 is installed on this machine.

Karl

On Mon, Oct 3, 2011 at 9:14 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> Thanks Karl. Is SP1 installed? Sachin, Ashesh - anything else you can
> think of that would be useful?
>
> On Mon, Oct 3, 2011 at 1:48 PM, Karl Wright <daddywri(at)gmail(dot)com> wrote:
>> 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(at)pgadmin(dot)org> wrote:
>>> On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri(at)gmail(dot)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
>>>
>>
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>