Hi - is this likely to be applied to an upcoming release? / How does a novice apply a patch..?
Thanks
-----Original Message-----
From: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Sent: 04 September 2019 22:48
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>; williamedwinallen@live.com; pgsql-bugs@lists.postgresql.org; Magnus Hagander
<magnus@hagander.net>;PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: BUG #15858: could not stat file - over 4GB
Thanks for looking into this.
On Fri, Aug 23, 2019 at 11:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Directly editing the configure script is Not Done ... or at least,
> such changes wouldn't survive the next correctly-done configure
> update. You have to edit configure.in (or one of the sub-files in
> config/) and then regenerate configure using autoconf.
>
> It seems likely that we *don't* need or want this for Cygwin; that
> should be providing a reasonable stat() emulation already.
> So probably you just want to add "AC_LIBOBJ(win32_stat)" to the stanza
> beginning
>
> I'd also recommend that stat() fill all the fields in struct stat,
> even if you don't have anything better to put there than zeroes.
> Otherwise you're just opening things up for random misbehavior.
>
Fixed.
> I'm not in a position to comment on the details of the conversion from
> GetFileAttributesEx results to struct stat, but in general this seems
> like a reasonable way to proceed.
>
Actually, due to the behaviour of GetFileAttributesEx with symbolic links I think that using GetFileInformationByHandle
insteadcan give a more resilient solution. Also, by using a handle we get a good test for ERROR_DELETE_PENDING. This is
theapproach for the attached patch.
Regards,
Juan José Santamaría Flecha