22.04.2024 00:49, Thomas Munro wrote:
On Mon, Apr 22, 2024 at 12:00 AM Alexander Lakhin <exclus...@gmail.com> wrote:
  From what I can see, the following condition (namely, -l):
                  if ($path =~ /^pg_tblspc\/(\d+)$/ && -l "$backup_path/$path")
                  {
                      push @tsoids, $1;
                      return 0;
                  }

is false for junction points on Windows (cf [1]), but the target path is:
Ah, yes, right, -l doesn't like junction points.  Well, we're already
using the Win32API::File package (it looks like a CPAN library, but I
guess the Windows perl distros like Strawberry are all including it
for free?).  See PostgreSQL::Test::Utils::is_symlink(), attached.
That seems to work as expected, but someone who actually knows perl
can surely make it better.  Then I hit the next problem:

readlink 
C:\cirrus\build/testrun/pg_combinebackup/002_compare_backups\data/t_002_compare_backups_primary_data/backup/backup1/pg_tblspc/16415:
Inappropriate I/O control operation at
C:/cirrus/src/test/perl/PostgreSQL/Test/Cluster.pm line 927.

https://cirrus-ci.com/task/5162332353986560

I don't know where exactly that error message is coming from, but
assuming that Strawberry Perl contains this code:

https://github.com/Perl/perl5/blob/f936cd91ee430786a1bb6068a4a7c8362610dd5f/win32/win32.c#L2041
https://github.com/Perl/perl5/blob/f936cd91ee430786a1bb6068a4a7c8362610dd5f/win32/win32.c#L1976

... then it's *very* similar to what we're doing in our own
pgreadlink() code.  I wondered if the buffer size might be too small
for our path, but it doesn't seem so:

https://github.com/Perl/perl5/blob/f936cd91ee430786a1bb6068a4a7c8362610dd5f/win32/win32.c#L1581C1-L1581C35

(I think MAX_PATH is 256 on Windows.)

If there is some unfixable problem with what they're doing in their
readlink(), then I guess it should be possible to read the junction
point directly in Perl using Win32API::File::DeviceIoControl()... but
I can't see what's wrong with it!  Maybe it's not the same code?

I wonder whether the target path (\??\) of that junction point is fully correct.
I tried:
> mklink /j "C:/src/postgresql/build/testrun/pg_combinebackup/002_compare_backups/data/t_002_compare_backups_primary_data/backup/backup1/pg_tblspc/test" \\?\C:\t1 Junction created for C:/src/postgresql/build/testrun/pg_combinebackup/002_compare_backups/data/t_002_compare_backups_primary_data/backup/backup1/pg_tblspc/test <<===>> \\?\C:\t1
and
my $path = 'C:/src/postgresql/build/testrun/pg_combinebackup/002_compare_backups/data/t_002_compare_backups_primary_data/backup/backup1/pg_tblspc/test';
my $result = readlink($path);
works for me:
result: \\?\C:\t1

Whilst with:
my $path = 'C:/src/postgresql/build/testrun/pg_combinebackup/002_compare_backups/data/t_002_compare_backups_primary_data/backup/backup1/pg_tblspc/16415';
readlink() fails with "Invalid argument".

> dir "C:/src/postgresql/build/testrun/pg_combinebackup/002_compare_backups/data/t_002_compare_backups_primary_data/backup/backup1/pg_tblspc"
04/22/2024  08:16 AM    <DIR>          .
04/22/2024  08:16 AM    <DIR>          ..
04/22/2024  06:52 AM    <JUNCTION>     16415 
[\??\C:\Users\ADMINI~1\AppData\Local\Temp\1zznr8FW5N\ts1backup]
04/22/2024  08:16 AM    <JUNCTION>     test [\\?\C:\t1]

> dir "\??\C:\Users\ADMINI~1\AppData\Local\Temp\1zznr8FW5N\ts1backup"
 Directory of C:\??\C:\Users\ADMINI~1\AppData\Local\Temp\1zznr8FW5N\ts1backup

File Not Found

> dir "\\?\C:\t1"
 Directory of \\?\C:\t1

04/22/2024  08:06 AM    <DIR>          .
04/22/2024  08:06 AM    <DIR>          ..
               0 File(s)              0 bytes

Though
> dir "C:/src/postgresql/build/testrun/pg_combinebackup/002_compare_backups/data/t_002_compare_backups_primary_data/backup/backup1/pg_tblspc/16415"
somehow really works:
 Directory of C:\src\postgresql\build\testrun\pg_combinebackup\002_compare_backups\data\t_002_compare_backups_primary_data\backup\backup1\pg_tblspc\16415

04/22/2024  06:52 AM    <DIR>          .
04/22/2024  06:52 AM    <DIR>          ..
04/22/2024  06:52 AM    <DIR>          PG_17_202404021

Best regards,
Alexander


Reply via email to