MIME-Version: 1.0
Date: Tue, 09 Aug 2022 17:59:33 +0700
From: r.zharkov@postgrespro.ru
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Michael Paquier
 <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Checking pgwin32_is_junction() errors
In-Reply-To: 
 <CA+hUKGJtJaKCuuEskzRkcGMjRYnf1aLQmEkzf=o-ZM=7fqNkow@mail.gmail.com>
References: 
 <CA+hUKGLfOOeyZpm5ByVcAt7x5Pn-=xGRNCvgiUPVVzjFLtnY0w@mail.gmail.com>
 <YmEOJwmmKPugH41o@paquier.xyz>
 <CA+hUKG+ntyS1CDxf5z9qNS41uYasqCQf+o44X3ALD9XnUmmqRA@mail.gmail.com>
 <CA+hUKGL97TZhXcaey8Vm0uKt6CTzyXDDQEvffHh6ZkkmAXvjcQ@mail.gmail.com>
 <e516eed3-3555-cdad-663e-e59e4a2b0355@dunslane.net>
 <205d5e64-6e0a-dede-5128-a55b54f4356f@dunslane.net>
 <CA+hUKGKn7Krpdx1+Wy5jMzKBZBP7hUX8igyMYXRRrDiQy_rPZw@mail.gmail.com>
 <CA+hUKGKWR3=B_=qg_+bmX=pjtQ5Zk_3Agco7xg8GgpvZBafJ7w@mail.gmail.com>
 <CA+hUKGK+V61MRXsjUEO5GnhmpveoL6v5Ud7by2DFwVTeZuUBeg@mail.gmail.com>
 <4590c37927d7b8ee84f9855d83229018@postgrespro.ru>
 <CA+hUKG+AZOyOoQx11PLF7Kk+SzMz98Hp_RyY-qqSQdM_NsB4PA@mail.gmail.com>
 <CA+hUKGJtJaKCuuEskzRkcGMjRYnf1aLQmEkzf=o-ZM=7fqNkow@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <dec272b83ba31a2f22e255dce4bd50aa@postgrespro.ru>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/dec272b83ba31a2f22e255dce4bd50aa%40postgrespro.ru>
Precedence: bulk

On 2022-08-09 05:44, Thomas Munro wrote:
> On Tue, Aug 9, 2022 at 8:30 AM Thomas Munro <thomas.munro@gmail.com> 
> wrote:
>> On Mon, Aug 8, 2022 at 8:23 PM <r.zharkov@postgrespro.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