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 по дате отправления: