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

Tom Lane писал(а) 2026-07-31 17:08:
> Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru> 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.)
>
We could try other approach - avoid changing zic and _dosmaperr()
and fix link() like this in src/port/win32link.c:

if (CreateHardLinkA(dst, src, NULL) == 0)
{
int returncode;

returncode = GetLastError();

if (returncode == ERROR_INVALID_FUNCTION)
errno = ENOTSUP;
else
dosmaperr(returncode);
return -1;
}
It will not affect other places where link() is called, and resolve
zic issue.
--
Best regards,

Vladlen Popolitov.