CreateHardLinkA reports ERROR_INVALID_FUNCTION if the target file
is on a filesystem that doesn't support hard links. _dosmaperr
maps that to EINVAL, which confuses zic.c into failure. zic.c is
expecting ENOTSUP if the filesystem lacks link support, and will
properly fall back to making a physical copy if it gets that.
Hence, add code to map ERROR_INVALID_FUNCTION to ENOTSUP.
(We could instead teach _dosmaperr to do that, but it's far from clear
that this would be appropriate as a global behavior: intuitively
it seems like EINVAL should be appropriate most of the time.)
We didn't need this before commit
aeb07c55f, because the tzcode
version we were using before that didn't have this particular
error-handling logic. Hence, no back-patch for now; but if we
decide to back-patch tzcode 2026b or later, we'll need this too.
Author: Vladlen Popolitov <v.popolitov@postgrespro.ru>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/
e6122f9b2eef9096f1f11ecc058bcd91@postgrespro.ru
*/
if (CreateHardLinkA(dst, src, NULL) == 0)
{
- _dosmaperr(GetLastError());
+ /*
+ * CreateHardLinkA reports ERROR_INVALID_FUNCTION if the target file
+ * is on a filesystem that doesn't support hard links. _dosmaperr
+ * would map that to EINVAL by default, but we want to report ENOTSUP
+ * because that will cause zic.c to fall back to making copies.
+ * However, EINVAL is probably the best translation in most cases, so
+ * tweak it here rather than changing _dosmaperr's behavior.
+ */
+ DWORD error = GetLastError();
+
+ if (error == ERROR_INVALID_FUNCTION)
+ errno = ENOTSUP;
+ else
+ _dosmaperr(error);
return -1;
}
else