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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, Emil Iggland <emil(at)iggland(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15858: could not stat file - over 4GB
Date: 2020-10-12 01:01:08
Message-ID: 20201012010108.GB2346@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Sat, Oct 10, 2020 at 08:34:48PM -0400, Tom Lane wrote:
> Nah, I fixed that hours ago (961e07b8c). jacana must not have run again
> yet.

Indeed, thanks. I have missed one sync here.

+ hFile = CreateFile(name,
+ GENERIC_READ,
+ (FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE),
+ &sa,
+ OPEN_EXISTING,
+ (FILE_FLAG_NO_BUFFERING | FILE_FLAG_BACKUP_SEMANTICS |
+ FILE_FLAG_OVERLAPPED),
+ NULL);
+ if (hFile == INVALID_HANDLE_VALUE)
+ {
+ CloseHandle(hFile);
+ errno = ENOENT;
+ return -1;
+ }
Why are we forcing errno=ENOENT here? Wouldn't it be correct to use
_dosmaperr(GetLastError()) to get the correct errno? This code would
for example consider as non-existing a file even if we fail getting it
because of ERROR_SHARING_VIOLATION, which should map to EACCES. This
case can happen with virus scanners taking a non-share handle on files
being looked at in parallel of this code path.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-10-12 03:27:18 Re: BUG #15858: could not stat file - over 4GB
Previous Message Pavel Stehule 2020-10-11 07:13:12 Re: BUG #16665: Segmentation fault

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-10-12 01:12:12 Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.
Previous Message David Christensen 2020-10-11 22:13:55 Re: [PATCH] Add `truncate` option to subscription commands