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  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Dmitry Dolgov
Дата:
Сообщение: Re: Index Skip Scan
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: Sort support for macaddr8