Re: BUG #17288: PSQL bug with COPY command (Windows)

On Wed, Nov 17, 2021 at 01:29:02PM +0300, Dmitry Koval wrote:
> Attachments: patch + screenshot with error.

Gulp.  I can reproduce this problem.

>      if (!GetFileInformationByHandle(hFile, &fiData))
>      {
> -        _dosmaperr(GetLastError());
> +        DWORD        error = GetLastError();
> +
> +        switch (error)
> +        {
> +            case ERROR_INVALID_PARAMETER:
> +            case ERROR_INVALID_FUNCTION:
> +            case ERROR_NOT_SUPPORTED:
> +
> +                /*
> +                 * Object is other than real file (stdout, for example). So
> +                 * need to call _fstat64 in this case. "struct stat" should
> +                 * match "struct __stat64", see "struct stat" definition.
> +                 */
> +                if (fileno >= 0)
> +                    return _fstat64(fileno, (struct __stat64 *) buf);
> +                else if (name)
> +                    return _stat64(name, (struct __stat64 *) buf);
> +        }
> +        _dosmaperr(error);
>          return -1;

Hmm.  _fstat64() and _stat64() have proved to be tricky to work with
and rather unworkable across all the build systems we support
(remember the 2GB file size problem, for example), which is why we
have the existing business of win32stat.c to begin with.  It seems to
me, also, that we could run into issues if we blindly map those error
codes to call a stat() function as fallback.  I am not sure that doing
a blind cast to __stat64 is going to work all the time, either.

I think that we had better never call GetFileInformationByHandle() if
we use a fileno that maps to stdin, stdout or stderr.  The 10000$
question is what to use though.  One option is to let our emulation
code fill in the gap for those three cases with at least st_mode
filled with S_IFIFO, then return 0 as error code :/

Just to be sure, this is the code path in psql's copy.c where we check
that a specified copystream is not a directory, right?
--
Michael