Re: zic: fix PostgreSQL build failure on filesystems without hard link support

Vladlen Popolitov  writes:
> Tom Lane писал(а) 2026-07-31 02:57:
>> Also, it occurs to me to wonder if we're doing this to ourselves.
>> Specifically, it looks like src/port/win32error.c's _dosmaperr
>> will map ERROR_NOT_SUPPORTED to EINVAL, due to the lack of any
>> table entry for ERROR_NOT_SUPPORTED.  Can you confirm which
>> underlying Windows error code is being returned?

> I have confirmed that the Windows error code returned by
> CreateHardLinkA() on exFAT is ERROR_INVALID_FUNCTION (numeric value 1).
> This code has no mapping in PostgreSQL's _dosmaperr(), which
> falls back to returning EINVAL (errno == 22). This is why zic
> receives EINVAL instead of ENOTSUP.

Interesting.  I wonder if it'd be sane to put in an explicit mapping
for ERROR_INVALID_FUNCTION, although I'm not quite sure whether to
prefer ENOTSUP or EOPNOTSUPP.  (If so, I'd be inclined to also add a
mapping for ERROR_NOT_SUPPORTED, but apparently that's not relevant to
the immediate problem.)

> Also I see in man: Linux returns EPERM for unsupported filesystems,
> FreeBSD returns EOPNOTSUPP. Neither returns ENOTSUP.

Oooh.  I didn't experiment on either, but I concur with your reading
of their man pages.  Also, NetBSD's man page says the same as FreeBSD,
and I quickly verified on NetBSD 10 that EOPNOTSUPP (45) is different
from ENOTSUP (86), unlike the situation on Linux.  So tzcode's
expectation of ENOTSUP is pretty widely broken already.

> Regarding symlink(): PostgreSQL maps symlink to pgsymlink(), which is
> implemented using NTFS junction points on Windows. Junction points work
> only with directories, not files. Since zic needs to create symbolic
> references to timezone data files, this mechanism is unsuitable, and
> zic correctly excludes symlink support using #ifdef HAVE_SYMLINK.

Right, so that part of it is not a problem.

But this is a mess :-(.  We're not doing the best possible job in
_dosmaperr, but it seems tzcode's expectations need some adjustment
anyway, and that side should probably get sorted before we decide
what to do in _dosmaperr.  I'll go consult further with them.

			regards, tom lane