At Thu, 18 Jul 2019 14:04:34 +0700, Жарков Роман <r.zharkov@postgrespro.ru> wrote in
<ECD07611-BBA8-4E9B-975C-50E59F7154DA@postgrespro.ru>
> Hello,
>
> Therefore, we suggest replace the deletion of a lock file by renaming it.
> unlink in windows is not an atomic operation.
> When we try to open the file between
> SetDispositionInformationFile and CloseFile we get ERROR_DELETE_PENDING ( see screenshot )
I found a mail in the arvhive.
https://www.postgresql.org/message-id/CABUevExwz9ncAk90Hb3Sb4MHeaOEyS59eTb_AKW9qFEjAidg5Q%40mail.gmail.com
> > > > One approach would be to rename the file into something indicating it's
> > > > being deleted, before actually deleting it.
> > > >
> > > >
> > > That would be an option (IIRC if you open with FILE_SHARE_DELETE, it can
> > > also be renamed). But if we can track the delete when we try to open it
> > and
> > > just treat it as "file does not exist", that seems cleaner.
> >
> > I'm not sure what exactly you're suggesting. But isn't there the issue
> > that such an approach will not interoperate with external tools?
> >
>
>
>
> I'll have to admit I wasn't thinking of external tools. The external tools
> would have to learn about pending-delete files themselves. So yeah, if we
> care about those then renaming them to something predictable and then
> instruct the third party tools to exclude such files would be a more
> complete fix.
STATUS_PENDING_DELETE is concealed under win32 API (seems like a kind of
misdesign if it is true that ERROR_PENDING_DELETE is defined but not actually
used as I saw in someone's blog.). AFAICS native interfaces like NtOpenFile
returns the native status code. That is a bit cumbersome but not too difficult
(as heard).
https://resources.infosecinstitute.com/calling-ntdll-functions-directly/
That said, I haven't succeeded even to open a file with it. (I replaced the path
with NT native path (\??\c:\blah..) since NtOpenFile doesn't accept the
user-friendly(?) paths).
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
