Re: BUG #13853: initdb to UNC path

This command

pg_ctl.exe initdb -D localhost\Users\nboardman\test
just creates the whole DB locally starting at the current directory, and th=
en going .\localhost\Users\... etc

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: Thursday, January 07, 2016 2:21 PM
To: John R Pierce
Cc: Nuri Boardman; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #13853: initdb to UNC path

John R Pierce <pierce@hogranch.com> writes:
> On 1/7/2016 8:14 AM, NBoardman@idtus.com wrote:
>> fixing permissions on existing directory=20
>> //localhost/Users/nboardman/test ... ok
>>=20
>> creating subdirectories ... initdb: could not create directory
>> "//localhost/Users": File exists

Hm.  AFAICS, this failure must have occurred inside pg_mkdir_p, and what it=
 implies is that stat(2) either failed entirely for "//localhost/Users", or=
 claimed it isn't a directory.  Either one seems more like a system problem=
 than our problem.

> does it work if you leave out the \\localhost part?   using network=20
> paths for database storage is NOT recommended.

This is true, and it's not an unreasonable bet that stat() is misbehaving b=
ecause it's a network path.

Having said that, I wonder why initdb is coded to use pg_mkdir_p rather tha=
n plain mkdir for creating subdirectories after the datadir has been create=
d.  There is basically no advantage there, and there's certainly scope for =
things to go wrong, as this example shows.

            regards, tom lane