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


Reply via email to