At Thu, 18 Jul 2019 14:04:34 +0700, Жарков Роман <r.zhar...@postgrespro.ru> wrote in <ecd07611-bba8-4e9b-975c-50e59f715...@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
