I see no evidence that SP1 is installed on this machine. Karl On Mon, Oct 3, 2011 at 9:14 AM, Dave Page <dpage@xxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxx> wrote: >>> On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander <magnus@xxxxxxxxxxxx> wrote: >>>> On Fri, Sep 30, 2011 at 15:34, Karl Wright <daddywri@xxxxxxxxx> 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 > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
