Re: Fix fseek() detection of unseekable files on WIN32

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix fseek() detection of unseekable files on WIN32
Date: 2023-03-15 04:57:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, Mar 14, 2023 at 01:26:27PM +0100, Juan José Santamaría Flecha wrote:
> As highlighted in [1] fseek() might fail to error even when accessing
> unseekable streams.
> PFA a patch that checks the file type before the actual fseek(), so only
> supported calls are made.

+ * streams, so harden that funcion with our version.

+extern int pgfseek64(FILE *stream, pgoff_t offset, int origin);
+extern pgoff_t pgftell64(FILE *stream);
+#define fseeko(stream, offset, origin) pgfseek64(stream, offset, origin)
+#define ftello(stream) pgftell64(stream)

What about naming the internal wrappers _pgfseeko64() and
_pgftello64(), located in a new file named win32fseek.c? It may be
possible that we would need a similar treatment for fseek(), in the
future, though I don't see an issue why this would be needed now.

+ if (GetFileType((HANDLE) _get_osfhandle(_fileno(stream))) != FILE_TYPE_DISK)
+ {
+ errno = ESPIPE;
+ return -1;
+ }
Shouldn't there be cases where we should return EINVAL for some of the
other types, like FILE_TYPE_REMOTE or FILE_TYPE_UNKNOWN? We should
return ESPIPE only for FILE_TYPE_PIPE and FILE_TYPE_CHAR, then?

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-03-15 04:59:35 Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken
Previous Message Nathan Bossart 2023-03-15 04:23:48 Re: psql \watch 2nd argument: iteration count