winapi - C++/Win32: How to wait for a pending delete to complete? -

winapi - C++/Win32: How to wait for a pending delete to complete? -

solved: * workable solution: @sbi * explanation happens: @hans * explanation why openfile doesn't pass through "delete pending": @benjamin

the problem: our software in big part interpreter engine proprietary scripting language. scripting language has ability create file, process it, , delete file. these separate operations, , no file handles kept open in between these operations. (i.e. during file create handle created, used writing, closed. during file processing portion, separate file handle opens file, reads it, , closed @ eof. , finally, delete uses ::deletefile has utilize of filename, not file handle @ all).

recently we've come realize particular macro (script) fails able create file @ random subsequent time (i.e. succeeds during first hundred iterations of "create, process, delete", when comes creating hundred , first time, windows replies "access denied").

looking deeper issue, have written simple programme loops on this:

while (true) { handle hfile = createfilea(pszfilename, file_all_access, file_share_read, null, create_new, file_attribute_normal, null); if (hfile == invalid_handle_value) homecoming openfailed; const dword dwwrite = strlen(pszfilename); dword dwwritten; if (!writefile(hfile, pszfilename, dwwrite, &dwwritten, null) || dwwritten != dwwrite) homecoming writefailed; if (!closehandle(hfile)) homecoming closefailed; if (!deletefilea(pszfilename)) homecoming deletefailed; }

as can see, direct win32 api, , pretty darn simple. create file, write it, close handle, delete it, rinse, repeat...

but somewhere along line, i'll access denied (5) error during createfile() call. looking @ sysinternal's processmonitor, can see underlying issue there pending delete on file while i'm trying create again.

questions: * there way wait delete complete? * there way observe file pending deletion?

we have tried first option, waitforsingleobject() on hfile. hfile closed before waitforsingleobject executes, , waitforsingleobject returns wait_failed. clearly, trying wait closed handle doesn't work.

i wait on alter notification folder file exists in. however, seems extremely overhead-intensive kludge problem (to wit: in tests on win7 x64 e6600 pc typically fails on iteration 12000+ -- on other machines, can happen iteration 7 or 15 or 56 or never).

i have been unable discern createfile() arguments explicitly allow ether. no matter arguments createfile has, not okay opening file any access when file pending deletion. , since can see behavior on both xp box , on x64 win7 box, quite core ntfs behavior "as intended" microsoft. need solution allows os finish delete before effort proceed, preferably w/o tying cpu cycles needlessly, , without extreme overhead of watching folder file in (if possible).

thanks taking time read , post response. clarifying questions welcome!

[1] yes, loop returns on failure write or failure close leaks, since simple console test app, app exits, , windows guarantees handles closed os when process completes. no leaks exist here.

bool deletefilenowa(const char * pszfilename) { // determine path in store temp filename char szpath[max_path]; strcpy(szpath, pszfilename); pathremovefilespeca(szpath); // generate guaranteed unique temporary filename house pending delete char sztempname[max_path]; if (!gettempfilenamea(szpath, ".xx", 0, sztempname)) homecoming false; // move real file dummy filename if (!movefileexa(pszfilename, sztempname, movefile_replace_existing)) homecoming false; // queue deletion (the os delete when handles (ours or other processes) close) if (!deletefilea(sztempname)) homecoming false; homecoming true; }

why don't first rename file deleted, , delete it?

use gettempfilename() obtain unique name, utilize movefile() rename file. delete renamed file. if actual deletion indeed asynchronous , might conflict creation of same file (as tests seems indicate), should solve problem.

edit: of course, if analysis right , file operations happen asynchronous, might introduce problem effort delete file before renaming done. maintain trying delete in background thread.

edit #2: if hans right (and i'm inclined believe analysis), moving might not help, because might not able rename file that's open process. (but might, don't know this.) if that's indeed case, other way can come "keep trying". have wait few milliseconds , retry. maintain timeout give when doesn't help.

c++ winapi file-io ntfs