C++/Win32: How to Wait for a Pending Delete to Complete

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

First rename the file to be deleted, and then delete it.

Use GetTempFileName() to obtain a unique name, and then use MoveFile() to rename the file. Then delete the renamed file. If the actual deletion is indeed asynchronous and might conflict with the creation of the same file (as your tests seems to indicate), this should solve the problem.

Of course, if your analysis is right and file operations happen somewhat asynchronous, this might introduce the problem that you attempt to delete the file before the renaming is done. But then you could always keep trying to delete in a background thread.

If Hans is right (and I'm inclined to believe his analysis), then moving might not really help, because you might not be able to actually rename a file that's open by another process. (But then you might, I don't know this.) If that's indeed the case, the only other way I can come up with is "keep trying". You would have to wait for a few milliseconds and retry. Keep a timeout to give up when this doesn't help.

How to prevent my function from delayed deleting in RemoveDirectory() WINAPI?

First of all, I apologize for asking such a misleading question but...

I have found my mistake, It is not in the function that I posted in the question.

I have a project where I used my function DirectoryExists, and there was a function from the header "opendir" (It is a portable version of linux header for Windows and there are probably WINAPI HANDLEs inside of it). And I forgot to close the directory after I've opened it to check if it exists.

bool DirectoryExists(const std::string & path)
{
    DIR *dir = opendir(path.c_str());
    if (dir) {
        return true;
    }
    else
        return false;
}

And I've corrected the error:

bool DirectoryExists(const std::string & path)
{
    DIR *dir = opendir(path.c_str());
    closedir(dir);
    if (dir) {
        return true;
    }
    else
        return false;
}

I hope that this question can help someone to understand why RemoveDirectory() could work as not expected. There could be some handles that you did not notice and It's not that clear If you're not a professional Windows programmer.

Windows - Opening a file from code and wait for it to be closed

It sounds like you want to know when the file handle is "closed", not necessiarly when the program that operated on that file has exited.

Your question is closely related to this question. You could reference that to periodically poll the process handle to see what files are open. There will be timing issues - it might take a few seconds for the process to open the file in the first place.

There are also tools such as Handle.exe that may be useful.

However - none of these solutions are perfect. Some apps, including Notepad.exe, just open the file, read the contents, and immediately close the handle. When the user clicks "save", the file is re-opened for writing, contents saved back to disk, then the file handle is closed again.

A simpler approach would be to periodically poll the last-modified timestamp on the file via GetFileTime. When it changes, you could assume the file has been "Saved". Or apply this technique with some combination of the above and/or waiting for the application that was launched to exit.

DeleteFile of an EXE immediately after Process.WaitForExit fails

There's a few reasons way your exe could still be locked when it's done executing. some have to do with your code and some with the system. The two main reasons I can think off for your code would be:

How you close the filestream when you copy the exe file to the temp location, if it's not released explicitly the release timing might change from time to time.

the second is even though the process is done executing doesn't mean it's done in a system perspective.

The first one can be avoid the second can be monitored in the process list BUT you still have a bag of possible locks (your program executing twice in parallel, virus scan some one manually cleaning the temp folder, disc cleanup wizard). So I'd suggest either to rework the logic of the program. If the executeable is written in c# load the binary and execute the program instead of copying the file.

If you for some reason needs to copy the file every time it's executed spawn a low priority cleanup thread. let it try to clean up after the WaitForExit call if that fails make it try again after x milliseconds if that fails again try after 2x and so forth.

That being said I guess their would be (probably unmanaged) API calls to look for file locks on a system level. Personally I would just have the system it self figure that out though

---

Related Topics