Re: BUG #5267: initdb fails on AIX: could not identify current directory

I wrote a simple program - just calling getcwd() and I added some extra text
to exec.c - to know where it is at. You should recognize it.

michael(at)x054:[/data/home/michael]ls -l /usr/local/pgsql/bin/mytest
-rwx------ 1 root system 4793 Jan 07 15:39
/usr/local/pgsql/bin/mytest
michael(at)x054:[/data/home/michael]chmod a+rx /usr/local/pgsql/bin/mytest
michael(at)x054:[/data/home/michael]r su
su - postgres
postgres(at)x054:[/home/postgres]/usr/local/pgsql/bin/mytest
/usr/local/pgsql/bin/mytest: 1
PATH_MAX:1023
/home/postgres
postgres(at)x054:[/home/postgres]
michael(at)x054:[/data/home/michael]
michael(at)x054:[/data/home/michael]cat test.c
#include <limits.h>
#include <unistd.h>
main(int argc, char **argv)
{
char buf[PATH_MAX];

printf("%s: %d\n", argv[0], argc);
printf("PATH_MAX:%d\n", PATH_MAX);
printf("%s\n", getcwd(buf, PATH_MAX));
}

===========
And I am only running the command from /home/postgres

postgres(at)x054:[/home/postgres]ls -ld .
drwxr-xr-x 2 postgres staff 256 Jan 05 13:45 .

postgres(at)x054:[/home/postgres]ls -l
/usr/local/pgsql/bin
total 18760
-rwxr-xr-x 1 root system 79898 Jan 05 13:33 clusterdb
-rwxr-xr-x 1 root system 79554 Jan 05 13:33 createdb
-rwxr-xr-x 1 root system 79732 Jan 05 13:33 createlang
-rwxr-xr-x 1 root system 82515 Jan 05 13:33 createuser
-rwxr-xr-x 1 root system 76661 Jan 05 13:33 dropdb
-rwxr-xr-x 1 root system 82087 Jan 05 13:33 droplang
-rwxr-xr-x 1 root system 76613 Jan 05 13:33 dropuser
-rwxr-xr-x 1 root system 686273 Jan 05 13:33 ecpg
-rwxr-xr-x 1 root system 101639 Jan 07 15:34 initdb
-rwxr-xr-x 1 root system 4793 Jan 07 15:39 mytest
-rwxr-xr-x 1 root system 37341 Jan 05 13:33 pg_config
-rwxr-xr-x 1 root system 31437 Jan 05 13:33 pg_controldata
-rwxr-xr-x 1 root system 52157 Jan 05 13:33 pg_ctl
-rwxr-xr-x 1 root system 392643 Jan 05 13:33 pg_dump
-rwxr-xr-x 1 root system 103892 Jan 05 13:33 pg_dumpall
-rwxr-xr-x 1 root system 46554 Jan 05 13:33 pg_resetxlog
-rwxr-xr-x 1 root system 186965 Jan 05 13:33 pg_restore
-rwxr-xr-x 1 root system 6842028 Jan 05 13:33 postgres
lrwxrwxrwx 1 root system 8 Jan 05 13:44 postmaster ->
postgres
-rwxr-xr-x 1 root system 388374 Jan 05 13:33 psql
-rwxr-xr-x 1 root system 82335 Jan 05 13:33 reindexdb
-rwxr-xr-x 1 root system 47359 Jan 05 13:33 vacuumdb

postgres(at)x054:[/home/postgres]/usr/local/pgsql/bin/initdb -D
/usr/local/pgsql/data
resolve_symlinks() orig_wd: MAXPGPATH == 1024
could not identify path directory: The file access permissions do not allow
the specified action.
find_my_exec(): MAXPGPATH == 1024
could not identify current directory: The file access permissions do not
allow the specified action.
find_my_exec(): MAXPGPATH == 1024
could not identify current directory: The file access permissions do not
allow the specified action.
The program "postgres" is needed by initdb but was not found in the
same directory as "initdb".
Check your installation.
postgres(at)x054:[/home/postgres]

=========
>From /tmp gives the same result.
postgres(at)x054:[/home/postgres]cd /tmp
postgres(at)x054:[/tmp]/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
resolve_symlinks() orig_wd: MAXPGPATH == 1024
could not identify path directory: The file access permissions do not allow
the specified action.
find_my_exec(): MAXPGPATH == 1024
could not identify current directory: The file access permissions do not
allow the specified action.
find_my_exec(): MAXPGPATH == 1024
could not identify current directory: The file access permissions do not
allow the specified action.
The program "postgres" is needed by initdb but was not found in the
same directory as "initdb".
Check your installation.
postgres(at)x054:[/tmp]

=========

I ran my test program with larger and smaller MAXPGPATH constants. 2046
(1023 * 2) was the largest I tested and it worked fine. When it was shorted
the call failed. I did not test the error message.

On Thu, Jan 7, 2010 at 4:25 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Jan 7, 2010 at 10:00 AM, Michael Felt <mamfelt(at)gmail(dot)com> wrote:
> > michael(at)x054:[/data/prj/postgresql-8.4.2/src]grep cwd */*.c
> > Well, unless you redefine it...
> > port/exec.c:#define getcwd(cwd,len) GetCurrentDirectory(len, cwd)
>
> If you look at the context of this #define you'll see that it only
> applies to Windows.
>
> > port/exec.c: char cwd[MAXPGPATH],
> > port/exec.c: if (!getcwd(cwd, MAXPGPATH))
> > port/exec.c: join_path_components(retpath, cwd,
> argv0);
> > port/exec.c: join_path_components(retpath, cwd, argv0);
> > port/exec.c: join_path_components(retpath,
> cwd,
> > test_path);
> > port/exec.c: * getcwd() to figure out where the heck we're at.
> > port/exec.c: * getcwd() to give us an accurate, symlink-free path.
> > port/exec.c: if (!getcwd(orig_wd, MAXPGPATH))
> > port/exec.c: if (!getcwd(path, MAXPGPATH))
> >
> >
> > Now I have no idea what is being called. I hope you do.
>
> It looks to me like bin/initdb/initdb.c:main() is calling
> port/exec.c:find_other_exec() which is calling
> port/exec.c:find_my_exec() which is calling getcwd(). So it's
> probably the directory you were in when you ran initdb that is the
> problem. For example:
>
> cd $HOME
> mkdir delete-me
> cd delete-me
> rmdir $HOME/delete-me
> initdb
>
> Produces:
>
> could not identify current directory: No such file or directory
> could not identify current directory: No such file or directory
> could not identify current directory: No such file or directory
> The program "postgres" is needed by initdb but was not found in the
> same directory as "initdb".
> Check your installation.
>
> This is very similar to what you got except that for you it's
> complaining about permissions rather than existence. I would try
> running initdb from someplace like / or /tmp and see if that works.
>
> I have to say that the error message that is produced by the above
> test case could easily send one looking in the wrong direction, and
> could perhaps stand to be improved. Could we just do getcwd() once,
> bail out if it fails, and then stash the results, rather than
> continuing on and eventually producing a misleading error message?
>
> ...Robert
>