Re: [SOLVED] Re: [GENERAL] initdb error: "could not identify current

[OpenMacNews]

tom,
We're doing the best we can already: when the failure occurs, we really
don't know which directory is the problem, and cannot find out because
we can't navigate above it to find out its name.
good point.  catch-22.
at the very least, some knowledgeable commentary in 
docs/FAQ/howto/Troubleshooting/etc could well be useful ...

I note that pwd is not any better:
g42:~ tgl$ mkdir ~/zit
g42:~/zit tgl$ mkdir ~/zit/zap
g42:~/zit tgl$ chmod 111 ~/zit
g42:~/zit tgl$ cd ~/zit/zap
g42:~/zit/zap tgl$ pwd
/Users/tgl/zit/zap
g42:~/zit/zap tgl$ /bin/pwd
pwd: : Permission denied
g42:~/zit/zap tgl$
interesting.  i need to read-up/monkey-around a bit b4 it bites me in the a__ 
again.

(bash is probably not doing anyone any favors by masking the problem in
its built-in PWD command.)
being primarily a tcsh user (yes, i'm old), i did'na kno that.  so *that's* the 
diff bet pwd and /bin/pwd on _your_ sys, yes?

You need to try to reconstruct how /Volumes/data/ got to be that way,
and see if it was simple pilot error or if some tool messed up the
permissions for you.
of course, you're right.  i'm betting on occam's razor --> 'pilot error' 
(hence, the "(or, what have i done now?)" in the Sub:), but due diligence _is_ 
called for. (there's a cute/useful mount manager util called SharePoints which 
i tried a while back that i _think_ may have made it EASY for me to screw 
things up ... not their fault, tho)

again, tom, thanks! now on to make postfix behave w/ pgsql8rc1! =)
best,
richard
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [SOLVED] Re: [GENERAL] initdb error: "could not identify current directory" (or, what have i done now?)

[Tom Lane]

OpenMacNews <[EMAIL PROTECTED]> writes:
> whoa! i wasn't suggesting that at all ... rather, perhaps, simply a perms 
> check 
> from within the initdb script and an 'informative' error to the
> end-user.

We're doing the best we can already: when the failure occurs, we really
don't know which directory is the problem, and cannot find out because
we can't navigate above it to find out its name.

I note that pwd is not any better:

g42:~ tgl$ mkdir ~/zit
g42:~/zit tgl$ mkdir ~/zit/zap
g42:~/zit tgl$ chmod 111 ~/zit
g42:~/zit tgl$ cd ~/zit/zap
g42:~/zit/zap tgl$ pwd
/Users/tgl/zit/zap
g42:~/zit/zap tgl$ /bin/pwd
pwd: : Permission denied
g42:~/zit/zap tgl$ 

(bash is probably not doing anyone any favors by masking the problem in
its built-in PWD command.)

There are limited situations where it makes sense to create a directory
that has execute but not read permissions ("drop box" directories being
the main thing I can think of offhand).  But it's simply wrong to
create a directory that way without a very specific purpose in mind.
You need to try to reconstruct how /Volumes/data/ got to be that way,
and see if it was simple pilot error or if some tool messed up the
permissions for you.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [SOLVED] Re: [GENERAL] initdb error: "could not identify current

[OpenMacNews]

hi tom,
   % ls -ald /Volumes/data
drwxr-x--x  12 openmac wheel 408 Nov 27 15:25 /Volumes/data/
Ah-hah, yes that's undoubtedly it.
and, since i've cleared that up pgsql is, again, behaving. yay.
for posterity's -- and other OSX users' -- sake, that's:
for the relevant drives/mounts in /Volumes, you need:
  perms >= 555 (i use)
  group should include your pgsql unprivileged user
   'default' ownership, i believe, is root:admin for mounts, hence your 
pgsql user
   would need to be added as a user to grup:admin

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?
I'm not in the business of reimplementing getcwd(); especially not to
deal with a problem that will break many other things besides Postgres.
whoa! i wasn't suggesting that at all ... rather, perhaps, simply a perms check 
from within the initdb script and an 'informative' error to the end-user. if i 
were the 1st/only to see such an issue, i'd, of course, not even bother with 
the suggestion ... but, as we've seen, it's raised its ugly head elsewhere 
(google: 'getcwd initdb')

I'd suggest filing a bug against whatever tool you used to create
/Volumes/data/, suggesting that they adopt a less brain-dead default
permissions setting.  Execute-only on a mount point is just silly.
i have a suspicion it has to do with my filesharing/automount 
system/setup/settings.  i'd had a bunch o' headaches a fairly long while back 
w/ getting Samba, AFS & NFS to play nice together.  i'm fairly sure perms were 
changed, and the mount points may have been (inadvertently?) munged.  why is 
'suddenly' changed in the last days, i have no flippin' idea as yet!

postgresql may have been, simply, the 1st (me <-- surprised) app to 'hit' the 
getcwd path sensitivity.

hence, i think i have to file a bug-report with myself ...  =)
two points o' feedback:
(a) without your help/suggestions, finiding this would've taken me a *lot* 
longer (thx!), and
(b) if this is in the pgsql docs (should it be?), i simply missed, misread or 
misunderstood it.

cheers,
richard
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [SOLVED] Re: [GENERAL] initdb error: "could not identify current directory" (or, what have i done now?)

[Tom Lane]

OpenMacNews <[EMAIL PROTECTED]> writes:
> on my sys:

>% ls -ald /Volumes/data
> drwxr-x--x  12 openmac wheel 408 Nov 27 15:25 /Volumes/data/

Ah-hah, yes that's undoubtedly it.

> 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?

I'm not in the business of reimplementing getcwd(); especially not to
deal with a problem that will break many other things besides Postgres.
I'd suggest filing a bug against whatever tool you used to create
/Volumes/data/, suggesting that they adopt a less brain-dead default
permissions setting.  Execute-only on a mount point is just silly.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

[SOLVED] Re: [GENERAL] initdb error: "could not identify current directory" (or, what have i done now?)

[OpenMacNews]

hi tom,
i think i got it ...
keeping in mind your question re: read perms, & reading this thread:

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
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])