Horton

Re: stat() vs ERROR_DELETE_PENDING, round N + 1

Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>

View thread View on postgr.es
From: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-09-29T10:26:25Z
Lists: pgsql-hackers 
On Tue, Sep 28, 2021 at 2:50 AM Thomas Munro <thomas.munro@gmail.com> wrote:

> On Thu, Sep 23, 2021 at 9:13 PM Juan José Santamaría Flecha
> <juanjo.santamaria@gmail.com> wrote:
> > When GetTempFileName() finds a duplicated file name and the file is
> pending for deletion, it fails with an "ERROR_ACCESS_DENIED" error code.
> That may describe the situation better than "ERROR_FILE_EXISTS".
>
> Thanks for looking.  Why do you think that's better?  I assume that's
> just the usual NT->Win32 error conversion at work.
>
> When a function returns an error caused by accessing a file
in DELETE_PENDING you should expect an EACCES. Nonetheless, if we can
emulate a POSIX behaviour by mapping it to EEXIST, that works for me. I
also consider that having the logic for DELETE_PENDING in a single function
is an improvement.

Regards,

Juan José Santamaría Flecha

Commits

  1. Check for STATUS_DELETE_PENDING on Windows.

  2. Fix our Windows stat() emulation to handle file sizes > 4GB.

  3. Attempt to handle pending-delete files on Windows