hi tom,
i think i got it ...
keeping in mind your question re: read perms, & reading this thread:
<http://groups.google.com/groups?hl=en&lr=&threadm=60b4un%24cqh%241%40dolphin.neosoft.com&rnum=2&prev=/groups%3Fq%3Dgetcwd%2520permissions%2520symlink%26hl%3Den%26lr%3D%26sa%3DN%26tab%3Dwg>
and noting there "suspicion would be that one of your mointpoints (like /usr)
has mangled permissions", it seems it's the mount point in the path of the
relevant symlink that needs the right perms.
for me that's, e.g., /Volumes/data
tho' i'd reported:
% ls -ald /var/data
lrwxr-xr-x 1 root wheel 27 /var/data -> /Volumes/data
its actually (apparently) the perms on the absolute dir path /Volumes/data that
matter ... to getcwd.
on my sys:
% ls -ald /Volumes/data
drwxr-x--x 12 openmac wheel 408 Nov 27 15:25 /Volumes/data/
the thread (above) mentioned changing perms to at least 555 on the mount point,
so i:
% chmod 755 /Volumes/data
% ls -ald /Volumes/data
drwxrwxr-x 12 openmac wheel 408 Nov 27 15:25 /Volumes/data/
and tried initdb again.
so far (!) it seems to run fine without the getced 'persmission denied' errors
from any directory.
i'll test this some more in the morn, and make sure i'm not deluding myself ...
if this *does* turn out to be the case, does it make sense to have the script
check perms up through the physical/path of the cwd and report with a more
specific/desciptive error if they're not at least 555 on the mount point?
thx & g'nite.
richard