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

Поиск
Список
Период
Сортировка
Искать
От
Michael Paquier
Тема
Re: BUG #15858: could not stat file - over 4GB
Дата
Msg-id
20201012010108.GB2346@paquier.xyz
Ответ на
Список
Дерево обсуждения
Re: BUG #15858: could not stat file - over 4GB Emil Iggland <emil@iggland.com>
Re: BUG #15858: could not stat file - over 4GB Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #15858: could not stat file - over 4GB Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Re: BUG #15858: could not stat file - over 4GB Michael Paquier <michael@paquier.xyz>
Re: BUG #15858: could not stat file - over 4GB Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Re: BUG #15858: could not stat file - over 4GB Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #15858: could not stat file - over 4GB Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Re: BUG #15858: could not stat file - over 4GB Michael Paquier <michael@paquier.xyz>
Re: BUG #15858: could not stat file - over 4GB Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #15858: could not stat file - over 4GB Michael Paquier <michael@paquier.xyz>
Re: BUG #15858: could not stat file - over 4GB Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #15858: could not stat file - over 4GB Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Re: BUG #15858: could not stat file - over 4GB Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #15858: could not stat file - over 4GB Michael Paquier <michael@paquier.xyz>
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
В списке pgsql-hackers по дате отправления
От: David Christensen
Дата:
От: Michael Paquier
Дата:
FAQ