Re: Checking pgwin32_is_junction() errors
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: r.zharkov@postgrespro.ru
Cc: Andrew Dunstan <andrew@dunslane.net>,
Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-10-12T04:05:18Z
Lists: pgsql-hackers
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.
Commits
-
Fix readlink() for non-PostgreSQL junction points on Windows.
- f71007fbb3b8 16.0 landed
-
Fix stat() for recursive junction points on Windows.
- 4517358ee782 16.0 landed
-
aix: fix misreading of condition in 8f12a4e7add
- 7e29a79a46d3 16.0 cited
-
Make unlink() work for junction points on Windows.
- f357233c9db8 16.0 landed
-
Replace pgwin32_is_junction() with lstat().
- 5fc88c5d53e4 16.0 landed
-
Provide lstat() for Windows.
- c5cb8f3b770c 16.0 landed