> On 30 Nov 2021, at 21:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> Scratch that, all the copying for tests 001 through 003 had failed. I clearly
>> need another coffee.
>> The question still stands though, does anyone have any ideas on what could've
>> happened as I'm currently drawing a blank?
>
> Dunno, but it strikes me that the libpq code issuing this error is not up
> to our usual quality standards. It's just assuming that the stat()
> failure is ENOENT, and I have a sneaking suspicion that that's not so.
>
> I'm inclined to suggest that we start by changing that code
> to look like, say,
>
> if (stat(fnbuf, &buf) != 0)
> ...
>
> and see what we learn.
That seems like a change worthy of doing regardless, so +1 on trying this. We
can't use %m in frontend though can we? Isn't using strerror_r() like in the
attached what we need to do? If so I can go ahead and do that, and it
shouldn't make the buildfarm any worse off than it is, and ideally we'll get
clues as to why msys is happy to copy the files with Perl but not read them
from C.
--
Daniel Gustafsson https://vmware.com/
