Tom Lane писал(а) 2026-07-31 20:07:
> Vladlen Popolitov <v.popolitov@postgrespro.ru> writes:
>> Tom Lane писал(а) 2026-07-31 17:08:
>>> 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.
>
>> We could try other approach - avoid changing zic and _dosmaperr()
>> and fix link() like this in src/port/win32link.c:
>
>> if (returncode == ERROR_INVALID_FUNCTION)
>> errno = ENOTSUP;
>> else
>> dosmaperr(returncode);
>
> Yeah, that sounds like the solution with the smallest blast radius.
> We know that ERROR_INVALID_FUNCTION means this for link(), but
> it's hardly clear that that applies across-the-board; it seems
> like EINVAL is probably the best translation in other cases.
>
> Another advantage is that we don't have to sync it with changes in
> zic.c: this will still do what we want after Eggert's changes of
> today[1] arrive, whereas other answers might not.
>
> I'll go make it so in a bit. Thanks for the report!
>
I have already created and tested a new patch based on this idea.
It fixes the link() error handling. The patch also fixes dolink()
on Linux and FreeBSD, since these platforms are affected as well.
I hope this can be fixed in upstream tzcode. Otherwise, we can
apply the patch only to our PostgreSQL code.
ENOTSUP is the constant returned on macOS, where this code
works without problems.
I also verified that PostgreSQL build on Ubuntu with an exFAT
drive fails with EPERM (Operation not permitted).
This patch fixes the code for Linux and the *BSD systems.
I tested it on exFAT.
It is worth noting that exFAT is a modern filesystem supported
by all major operating systems. It is commonly used as a portable
filesystem for exchanging data between drives. Supporting it
would be beneficial.
--
Best regards,
Vladlen Popolitov.
