Re: Checking pgwin32_is_junction() errors

On 2022-08-09 05:44, Thomas Munro wrote:
> On Tue, Aug 9, 2022 at 8:30 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
> wrote:
>> On Mon, Aug 8, 2022 at 8:23 PM <r(dot)zharkov(at)postgrespro(dot)ru> wrote:
>> > "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.
>
>> ... Would it
>> be better to say: if it doesn't begin with "\??\X:", where X could be
>> any letter, then don't modify it?
>
> Concretely, I wonder if this is a good fix at least in the short term.
> Does this work for you, and do the logic and explanation make sense?

Yes, this patch works well with my junction points.
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]

After hours of reading the documentation and debugging, it seems to me
we can use REPARSE_GUID_DATA_BUFFER structure instead of our
REPARSE_JUNCTION_DATA_BUFFER [1]. DataBuffer doesn't contain any
prefixes,
so we don't need to strip them. But we still need to construct a correct
volume name if a junction point is a volume mount point. Is it worth to
check this idea?

[1]
https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-reparse_guid_data_buffer