Re: Pinned files at Windows

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Pinned files at Windows
Date: 2019-06-03 20:37:30
Message-ID: c5214f90-eff8-f8ca-74e2-dbfb8a58957a@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.06.2019 22:15, Robert Haas wrote:
> On Thu, May 30, 2019 at 3:25 AM Konstantin Knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2019-06-03 21:03:16 Re: Sort support for macaddr8
Previous Message Dmitry Dolgov 2019-06-03 20:31:33 Re: Index Skip Scan