Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file
От | Michael Paquier |
---|---|
Тема | Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file |
Дата | |
Msg-id | CAB7nPqRy1EY=w17bydWvBpHvgsUOiPNcvz=zkLr6W=zGujvE0g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING
file
|
Список | pgsql-bugs |
On Mon, Aug 22, 2016 at 10:17 PM, Magnus Hagander <magnus@hagander.net> wrote: > Not having looked in detail, but in pgwin32_safestat(), if the stat() call > fails, we return immediately without calling _dosmaperr(), don't we? So > we're still going to error out there with whatever the default mapping is, > and that's access denied. > > It's only if the the stat() call succeeds but the getting of extended > attributes fail that we actually call _dosmaperr(). Meh, you're right. How stupid I am here. So we could just reuse the first block of your patch when checking for (r < 0), but drop the second part that complicates GetFileAttributesEx if win32error.c gets completed for _dosmaperr as my last patch does, right? By the way, in your patch you really need to s/STATUS_DELETE_PENDING/ERROR_DELETE_PENDING or compilation just fails. -- Michael
В списке pgsql-bugs по дате отправления: