Re: Pinned files at Windows
От | Konstantin Knizhnik |
---|---|
Тема | Re: Pinned files at Windows |
Дата | |
Msg-id | c5214f90-eff8-f8ca-74e2-dbfb8a58957a@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Pinned files at Windows (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Pinned files at Windows
|
Список | pgsql-hackers |
On 03.06.2019 22:15, Robert Haas wrote: > On Thu, May 30, 2019 at 3:25 AM Konstantin Knizhnik > <k.knizhnik@postgrespro.ru> wrote: >> If call of stat() is succeed, then my assumption is that the only reason >> of GetFileAttributesEx >> failure is that file is deleted and returning ENOENT error code in this >> case is correct behavior. > In my experience, the assumption "the only possible cause of an error > during X is Y" turns out to be wrong nearly 100% of the time. Our job > is to report the errors the OS gives us, not guess what they mean. > This is what we are try to do now: r = stat(path, buf); if (r < 0) { if (GetLastError() == ERROR_DELETE_PENDING) { /* * File has been deleted, but is not gone from the filesystem yet. * This can happen when some process with FILE_SHARE_DELETE has it * open and it will be fully removed once that handle is closed. * Meanwhile, we can't open it, so indicate that the file just * doesn't exist. */ errno = ENOENT; return -1; } return r; } but without success because ERROR_DELETE_PENDING is never returned by Win32. And moreover, stat() doesn't ever return error in this case.
В списке pgsql-hackers по дате отправления: