Whaaaaat!!
At Thu, 19 Dec 2019 23:22:52 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
> Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> > At Thu, 19 Dec 2019 15:09:45 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
> >> Alexander Lakhin <exclusion@gmail.com> writes:
> >>> It seems that the check for ERROR_DELETE_PENDING was added to
> >>> pgwin32_safestat() blindly, the issue wasn't reproduced at that time:
> >>> https://www.postgresql.org/message-id/CAB7nPqRJV6trFta-Qzgi6j2feuYR2ZC%2BKHvWdHnbpDG2scTrxw%40mail.gmail.com
>
> >> Hmm, makes one wonder whether that's actually live code.
>
> > Even if it is actually dead code, it seems reasonable as it stands
> > since it is intending to read status of an existing file and the
> > caller is assumed not to be knowing of ERROR_ACCESS_DENIED.
>
> What I was wondering about was how come, if stat() can see the specific
> error code ERROR_DELETE_PENDING, we don't get to see that from CreateFile.
> The whole reason we have a problem here is that CreateFile won't return
> that code :-( ... so it seems possible that the code in pgwin32_safestat
> is just wrong because the case never happens.
Ugggh! My eyes automatically converted it to
ERROR_ACCESS_DENIED.. Yes, the condition never be true.
Even if we use ERROR_ACCESS_DENIED instaed, pgwin32_safestat cannot
tell STATUS_ACCESS_DENIED from STATUS_DELETE_PENDING. A possible
compromise would be the same looping with pgwin32_open, but I'm not
sure if it doesn't harm callers.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center