I have a c++ MFC Windows application that uses IShellDispatch to create a NameSpace. I first create a .zip file on disk using _wfopen_s, write the 16 bytes of magic numbers into the file and call fclose. Then I create the NameSpace giving it the zip filename. The IShellDispatch::NameSpace API returns me a Folder object and I call Folder::CopyHere. I am using a smart pointer for the IShellDispatch (IShellDispatchPtr) and when my routine finishes I have steped into the OS to see the call to Release is indeed made. So I am not leaking the shell object as far as I can tell. I also call Release on the Folder object the NameSpace API returns (again I stepped through the OS code to see that call was being made).
Everything works like a charm with a slight issue. After I return from the routine I wrote to do the above work, I have noticed when I go out to Windows Explorer that the file size for the zip file is "1 KB" (I am stepping through the code using the debugger so the process is suspended while I do this). I have also written a routine that opens the zip file and reads the zip file. But when I call the routine, there are only 16 bytes (the magic numbers) in the file. If I quit stepping through the code using the debugger and just run, a second later the file size grows and the actual data is in the zip file. I can open the .zip file by double clicking it and see there is nothing in it until I see it change on disk.
I can also call a dialog's DoModal method and while the dialog is code is executing the file finishes up.
What is going on? I don't appear to have any COM reference leaks on the namespace or folder. And whether I call DoModal or skip the call so the executation makes it way back to our windows event loop, the file becomes available to my application. None of this is script code that is executing but it appears that there is some asynchronous behavior involved. I need to know when I can actually open the file and get to the actual binary data in the file.
I don't see any events that tell me when the CopyHere operation is complete. And I don't have any problem doing a file open and reading the (16) bytes. So no lock is apparently on the file. So either my code has a bug that I have not yet found, or I need to do something until I am absolutely sure the file is ready for further processing.
R.D. Holland