On Thu, Aug 11, 2022 at 10:40 PM <r.zharkov@postgrespro.ru> wrote:
> On 2022-08-11 07:55, Thomas Munro wrote:
> >> I checked a few variants:
> >>
> >> 21.07.2022 15:11 <JUNCTION> HOME [\??\Volume{GUID}\]
> >> 09.08.2022 15:06 <JUNCTION> Test1 [\\?\Volume{GUID}\]
> >> 09.08.2022 15:06 <JUNCTION> Test2 [\\.\Volume{GUID}\]
> >> 09.08.2022 15:17 <JUNCTION> Test3 [\??\Volume{GUID}\]
> >> 09.08.2022 15:27 <JUNCTION> Test4 [C:\temp\1]
> >> 09.08.2022 15:28 <JUNCTION> Test5 [C:\HOME\Temp\1]
> >
> > One more thing I wondered about, now that we're following junctions
> > outside PGDATA: can a junction point to another junction? If so, I
> > didn't allow for that: stat() gives up after one hop, because I
> > figured that was enough for the stuff we expect inside PGDATA and I
> > couldn't find any evidence in the man pages that referred to chains.
> > But if you *are* allowed to create a junction "c:\huey" that points to
> > junction "c:\dewey" that points to "c:\louie", and then you do initdb
> > -D c:\huey\pgdata, then I guess it would fail. Would you mind
> > checking if that is a real possibility, and if so, testing this
> > chain-following patch to see if it fixes it?
>
> I made some junctions and rechecked both patches.
>
> 11.08.2022 16:11 <JUNCTION> donald [C:\huey]
> 11.08.2022 13:23 <JUNCTION> huey [C:\dewey]
> 11.08.2022 13:23 <JUNCTION> dewey [C:\louie]
> 11.08.2022 16:57 <DIR> louie
>
> With the small attached patch initdb succeeded in any of these
> "directories". If the junction chain is too long, initdb fails with
> "could not create directory" as expected.
Thanks for testing and for that fix! I do intend to push this, and a
nearby fix for unlink(), but first I want to have test coverage for
all this stuff so we can demonstrate comprehensively that it works via
automated testing, otherwise it's just impossible to maintain (at
least for me, Unix guy). I have a prototype test suite based on
writing TAP tests in C and I've already found more subtle ancient bugs
around the Windows porting layer... more soon.
