Tom Lane писал(а) 2026-07-31 17:08:
Vladlen Popolitov <[email protected]> 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.
