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

From: Michael Paquier <[email-masked]>
Date: Wed, 15 Mar 2023 13:57:28 +0900

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.
s/funcion/function/.

+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?
--
Michael

---

From: Juan José Santamaría Flecha <[email-masked]>
Date: Wed, 15 Mar 2023 12:18:25 +0100

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

Done.

> future, though I don't see an issue why this would be needed now.

Done.

> return ESPIPE only for FILE_TYPE_PIPE and FILE_TYPE_CHAR, then?

Done.

PFA a new version of the patch.

Regards,

Juan José Santamaría Flecha