Re: BUG #15858: could not stat file - over 4GB

On Thu, Sep 17, 2020 at 6:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <
> juanjo(dot)santamaria(at)gmail(dot)com> writes:
> > Thanks for the reminder. Please find attached a rebased version.
>
> (This hasn't shown up on -hackers yet, maybe caught in moderation?)
>

Thanks for looking into it. Finally, it went through. I will be removing
bug-list from now on.

>
> I took a quick look through this. I'm not qualified to review the
> actual Windows code in win32stat.c, but as far as the way you're
> plugging it into the system goes, it looks good and seems to comport
> with the discussion so far.
>
> One thing I noticed, which is a pre-existing problem but maybe now
> is a good time to consider it, is that we're mapping lstat() to be
> exactly stat() on Windows. That made sense years ago when (we
> believed that) Windows didn't have symlinks, but surely it no longer
> makes sense.
>

I will have to take a better look at it, but from a quick look it, all
lstat() calls seem to test just if the file exists, and that can be done
with a cheap call to GetFileAttributes(). Would a limited (but fast)
lstat(), where only st_mode could be informed, be acceptable?

>
> Another more trivial point is that it'd be good to run the new code
> through pgindent before committing.
>

I do not have pgindent in the WIN32 machine, but I will try to for the next
version.

Regards,

Juan José Santamaría Flecha