On Tue, Apr 11, 2023 at 02:43:25PM +0900, Michael Paquier wrote:
> After going through the installation of a Windows setup with meson and
> ninja under VS, I have checked that this is working correctly by
> myself, so I am going to apply that. One of the tests I have done
> involved feeding a
he
docs referring to it.
--
Michael
From 6ce0e6c996d263d1d9d7348e55756445c80daf2d Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 11 Apr 2023 14:33:29 +0900
Subject: [PATCH v4] fix fseek detection of unseekable files for WIN32
Calling fseek() on a handle to a non-seeking device such a
On Mon, Mar 20, 2023 at 07:06:22AM +0900, Michael Paquier wrote:
> Not sure about this one. I have considered it and dirmod.c includes
> also bits for cygwin, while being aimed for higher-level routines like
> rename(), unlink() or symlink(). This patch is only for WIN32, and
> aimed for common
On Sun, Mar 19, 2023 at 08:10:10PM +0100, Juan José Santamaría Flecha wrote:
> My approach was trying to make something minimal so it could be
> backpatchable. This looks fine for HEAD, but are you planning on something
> similar for the other branches?
Yes. This is actually not invasive down to
On Sun, Mar 19, 2023 at 12:45 PM Michael Paquier
wrote:
>
> In short, I was thinking among the lines of something like the
> attached, where I have invented a pgwin32_get_file_type() that acts as
> a wrapper of GetFileType() in a new file called win32common.c, with
> all the error handling we
g an approach like that.
--
Michael
From 3e778828a58751a0b562908176dcb76cabcc7945 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Sun, 19 Mar 2023 20:40:22 +0900
Subject: [PATCH v3] fix fseek detection of unseekable files for WIN32
Calling fseek() on a handle to a non-seeking device such as a pipe o
On Thu, Mar 16, 2023 at 10:08:44AM +0100, Juan José Santamaría Flecha wrote:
> IDK, this is just looking for the good case, anything else we'll fail with
> ESPIPE or EINVAL anyway. If we want to get the proper file type we can call
> fstat(), which has the full logic.
I am not sure, TBH. As
On Thu, Mar 16, 2023 at 2:05 AM Michael Paquier wrote:
> On Wed, Mar 15, 2023 at 12:18:25PM +0100, Juan José Santamaría Flecha
> wrote:
> > PFA a new version of the patch.
>
> +_pgftello64(FILE *stream)
> +{
> + DWORD fileType;
> +
> + fileType = GetFileType((HANDLE)
On Wed, Mar 15, 2023 at 12:18:25PM +0100, Juan José Santamaría Flecha wrote:
> PFA a new version of the patch.
+_pgftello64(FILE *stream)
+{
+ DWORD fileType;
+
+ fileType = GetFileType((HANDLE) _get_osfhandle(_fileno(stream)));
Hmm. I am a bit surprised here.. It seems to me
> 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?
>
Done.
PFA a new version of the patch.
Regards,
Juan José Santamaría Flecha
v2-0001-fix-fseek-detection-of-unseekable-files-for-WIN32.patch
Description: Binary data
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
Regards,
Juan José Santamaría Flecha
0001-fix-fseek-detection-of-unseekable-files-for-WIN32.patch
Description: Binary data
12 matches
Mail list logo
