views:

329

answers:

1

In Win32, your main thread's current working directory is set to the location the executable was launched from. My problem is that even after a call to SetCurrentDirectory() to somewhere else, the process apparently still has a filesystem object referencing this initial startup directory (verifiable with a tool like Process Explorer) - which means this director cannot be deleted by the process.

Does anybody here know of a not-too-hacky solution? I'm specifically running into the problem with a program that integrates with explorer (adding a verb to HKCR\Directory\shell registry key), I need to process files in a right-clicked directory and the remove the source directory, which is impossible because the initial working directory is set to, you guessed it, the right-clicked directory.

EDIT: I'll go for the "use helper launch-from-sane-directory" approach. It might not be super elegant, but it will work and doesn't require any nasty hacks.

+1  A: 

Your easiest solution may be to just spawn a little helper process that runs in whatever directory you specify (c:\, e.g.) and then just exit and let it do its thing. It may need to be synchronized with a mutex, or perhaps just retry two or three times on a timer...

I had another thought: You may be able to use CreateFile() with FILE_FLAG_DELETE_ON_CLOSE. Then it should go away when everyone lets go of it, but only if it was opened with FILE_SHARE_DELETE.

jeffamaphone
This would work, but feels a bit kludgy - might be the simplest solution, though.
snemarch
delete on close is an interesting idea, but CreateFile doesn't deal with directories (unless you use FILE_FLAG_BACKUP_SEMANTICS, but I'm not sure that would work, and it requires SE_BACKUP_NAME privileges) :)
snemarch
Perhaps... I only gave the docs a cursory examination when I remembered the delete on close thing...
jeffamaphone