Holy cow, I wrote a book!
When you change folders in a common file dialog,
the common file dialog calls SetCurrentDirectory
to match the directory you are viewing.
(Don't make me bring back the Nitpicker's Corner.)
Okay, the first reaction to this is,
"What? I didn't know it did that!"
This is the other shoe dropping in the
story of the curse of the current directory.
Now the question is, "Why does it do this?"
Actually, you know the answer to this already.
Many programs require that the current directory match the
directory containing the document being opened.
Now, it turns out, there's a way for you to say,
"No, I'm not one of those lame-o programs.
I can handle current directory being different from the
Don't change the current directory when using a common file dialog."
You do this by passing the OFN_NOCHANGEDIR flag.
(If your program uses the
IFileDialog interface, then
NOCHANGEDIR is always enabled.
Hooray for progress.)
But now that you know about this second curse, you can actually use it
as a counter-curse against the first one.
If you determine that a program is holding a directory open,
and you suspect that it is the victim of the curse of the current directory,
you can go to that program and open a common file dialog.
(For example, Save As.)
From that dialog, navigate to some other directory you don't plan on
removing, say, the root of the drive, or your desktop.
Then cancel the dialog.
Since the common file dialog changes the current directory,
you have effectively injected a SetCurrentDirectory
call into the target process,
thereby changing it from the directory you want to remove.
Note, however, that this trick works only if the application
in question omits the OFN_NOCHANGEDIR flag
when it calls GetSaveFileName.
In Explorer, you can easily call up a common file dialog by
typing Win+R then clicking Browse, and in versions of Windows
up through Windows XP, Explorer didn't pass the