Re: Checking pgwin32_is_junction() errors

From: r(dot)zharkov(at)postgrespro(dot)ru
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Checking pgwin32_is_junction() errors
Date: 2022-08-08 08:23:30
Message-ID: 4590c37927d7b8ee84f9855d83229018@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2022-08-06 08:02, Thomas Munro wrote:
>
> Pushed.
>
> Hmm, this stuff could *really* use a little test framework that's run
> by check-world, that exercises these various replacement operations.
> But I also suspect that problems in this area are likely to be due to
> concurrency. It's hard to make a simple test that simulates the case
> where a file is unlinked between system calls within stat() and hits
> the STATUS_DELETE_PENDING case. That check is code I cargo-culted in
> this patch. So much of the stuff we've had in the tree relating to
> that area has been wrong in the past...

Hello, hackers!

initdb on my windows 10 system stopped working after the commit
c5cb8f3b: "Provide lstat() for Windows."
The error message is: creating directory C:/HOME/data ... initdb:
error: could not create directory "C:/HOME": File exists

"C:/HOME" is the junction point to the second volume on my hard drive -
"\??\Volume{GUID}\" which name pgreadlink() erroneously strips here:
https://github.com/postgres/postgres/blob/7e29a79a46d30dc236d097825ab849158929d977/src/port/dirmod.c#L357.
So initdb could not stat the file with name "Volume{GUID}", tried to
create it and failed.
With the attached patch initdb works fine again.

--
regards,

Roman

Attachment Content-Type Size
dirmod.c.patch text/x-diff 514 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-08-08 08:33:22 Re: logical decoding and replication of sequences
Previous Message Amit Langote 2022-08-08 07:38:44 Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size