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 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #15858: could not stat file - over 4GB
|
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: