On 09/13/2011 02:44 PM, Thomas Kellerer wrote:
It turned out that it tries the following:
(Note that the selected data directory is c:\Daten\db\pgdata91)
icacls C:\ /grant "tkellerer":RX
(Changing the permission for the whole harddisk!!)
I forwarded your message to Dave Page in case the EDB folks needed to
look into this. He commented that:
"Aside from the fact that icacls is hanging for reasons unknown, it
appears to be doing what it is designed to do - it traverses up the path
from the data directory to the root directory, granting read/execute
permissions on each dir as it goes. It's a non-recursive grant (the
default - /T makes it recurse), and is done because a great deal of the
failures we used to see were caused by the user not having read or
execute permissions on one of the parents of the data directory (or
installation directory)."
... which to me explains why:
Then when I kill that process, the installer starts a new one with
icacls "C:\Daten" /grant "tkellerer":RX
So it didn't actually hang, but changing the permissions for the entire
harddisk (170GB taken) and the complete c:\Daten (~20GB) directory twice
would have taken ages.
As Dave noted, it's a non-recursive grant. It isn't changing the
permissions for C:\ and everything under it. It's only changing the
permissions for C:\ its self. It's then stepping down the path of
parents down to the datadir and doing the same thing to make sure you
have the required rights on every folder all the way down.
See:
http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx
and note the lack of the /t flag when icacls is called.
Given that, it's not clear why it's taking so long. A lock of some kind,
maybe? Anyway, it's *not* recursively changing the permissions on your HDD.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
