Hi hackers,
My Windows-on-Arm buildfarm animal (unicorn: Windows 11 Pro build 26200.9457,
aarch64, MSVC 19.50, meson, cassert) currently fails 13 TAP tests on
REL_19_STABLE, and all 13 have the same cause: Windows returns error code 448
for stat() on a tablespace path, src/port/win32error.c does not know that code,
and so the error is reported as the catch-all EINVAL ("Invalid argument").
The core regression suite passes (meson check: Ok:1 Fail:0); this is confined to
tests that use tablespaces.
In the logs:
LOG: unrecognized win32 error code: 448
ERROR: could not stat directory "pg_tblspc/16387/PG_19_202609165/5": Invalid argument
STATEMENT: CREATE TABLE test1 (a int) TABLESPACE tblspc1;
Error 448 is:
#define ERROR_UNTRUSTED_MOUNT_POINT 448L (winerror.h, Windows SDK 10.0.26100)
448 -> "The path cannot be traversed because it contains an untrusted mount point"
I think this is a newer Windows hardening behavior around reparse points. Since
PostgreSQL emulates symlinks with junction points (IO_REPARSE_TAG_MOUNT_POINT)
for pg_tblspc, paths under pg_tblspc are subject to it.
So, the mapping below is worth having on its own (an unmapped Win32 code
becoming EINVAL is never useful), but I suspect the real fix for tablespaces on
recent Windows is in pgsymlink(). I would appreciate a second opinion from
people who know the Windows file-system code better than I do, particularly on
whether populating PrintName is the right move.
Happy to run experiments on this machine.
best.
-greg
