Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file

On Wed, Jul 13, 2016 at 3:10 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Wed, Jul 13, 2016 at 10:06 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > Checking directly for STATUS_DELETE_PENDING would be the way to go,
> > likely with tweaks in basebackup.c. but like Takatsuka-san, I cannot
> > find anything around that would allow us to check for that.
> >
> > [1]: http://stackoverflow.com/questions/6680491/why-does-
> windows-return-error-access-denied-when-i-try-to-open-a-delete-pended-f
>
> Actually we may want to tweak stat() to not complain for a file with
> such a state.
>
>
That will still leave is with a race condition won't it? It'll just be much
smaller? The file could go into STATUS_DELETE_PENDING between the call to
stat() and the call to sendFile()/allocateFile().

Maybe that's an acceptable difference? If not, we also need to teach
AllocateFile() about the error.

If we're happy with just stat, it looks like we will have to add it to
pgwin32_safestat().

I don' t have a working window sbox for testing ATM (yeah yeah, it's on my
magic todo), but can someone confirm if calling stat() on such a deleted
flie sets the errorcode so it can be checked with GetLastError() *as well*
as setting errno? IIRC those functions do, but it needs to be checked. If
so, the attached might work? If not, then we need an extra call to
GetFileAttributesEx(), or rearrange those calls in a way to trap errors
there.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/