In my case invalid argument (root directory instead of specified data direc=
tory) was passed by installer to icacls. That's what I saw. It wasn't probl=
em of icacls, it was a problem in pgsql installer.
05.06.2012, 22:38, "Dave Page" <dpage@pgadmin.org>:
> On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>
>> =C2=A0Excerpts from grv87's message of s=C3=A1b may 19 10:28:47 -0400 20=
12:
>>> =C2=A0The following bug has been logged on the website:
>>>
>>> =C2=A0Bug reference: =C2=A0 =C2=A0 =C2=A06652
>>> =C2=A0Logged by: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Basil Peace
>>> =C2=A0Email address: =C2=A0 =C2=A0 =C2=A0grv87@yandex.ru
>>> =C2=A0PostgreSQL version: 9.1.3
>>> =C2=A0Operating system: =C2=A0 Windows 7 x64
>>> =C2=A0Description:
>>>
>>> =C2=A0I have been installing PostgreSQL 9.1.3.2, and I've noted that 'c=
reating
>>> =C2=A0database cluster' is too long. I have been waiting for a half of =
hour, and
>>> =C2=A0it hasn't finished.
>>> =C2=A0I've noted that installer calls icacls.exe with arguments:
>>> =C2=A0D:\ /grant "postgres":RX
>> =C2=A0This seems to be reported every once in a while. =C2=A0It looks li=
ke the
>> =C2=A0one-clunk installer is to blame. =C2=A0Maybe it's been fixed in so=
me more
>> =C2=A0recent version -- Dave Page would probably know.
>
> Just as an FYI, we are working on this. We've been able to reproduce
> it, and it appears that icacls (a Microsoft utility) will sometimes
> look at the ACL of every file/directory recursively when it grants the
> required privileges on higher level directories. The good news is that
> in none of the test we've done has it ever modified the ACL on the
> wrong thing - it just takes a long time if there are a lot of items on
> the filesystem. We've looked at third party alternatives to icacls,
> and they seem to exhibit similar traits. We're also going to look into
> other ways around the root problem.
