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
