RemoveDirectory problem

RemoveDirectory problem

I have a directory that contains a number of files.

I read them, then close them (I think I have closed them all)

I then delete all the files in the directory using the DeleteFile command - and all are deleted.

I then try to delete the directory using the RemoveDirectory command and it fails. I get the error message -
"The process cannot access the file because it is being used by another process."

Any suggestions on how I can get the delete the directory, or ensure all processes are finished?



15 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Just a thought -- what does GetCurrentDirectory() return when you're about to delete the directory? If you're in that directory, you probably won't be able to delete it.
OTOH, it may be due to "disk flushing" as well.

See also SHFileOperation (but that won't solve your problem -- it's just a shorter way for deletion).



The current directory was the one I was about to delete.

I have changed that, but still get the error.

It may be caused by disc flushing.

I may give the SHFile... function a try but you say it won't help.



Did you ever find the solution to this? I have exactly the same problem.I have tried flushing the files before closing them but it does not improve things for me.



WinNT (WinXP) will at times defer deletion of files/directoriesand may be returning a status not indicating success but ratherindicating file/directory deletion is deferred. After your application exits, plus some time, is the directory present or deleted?

Also, if current directory is (was)the directory being deleted (as mentioned by other poster) then you might possibly have a temp file open in that directory. e.g.

MD scratch

CD scratch

yourProgPathYourProg arg /opt

Might not only create the files you explicitly create into current directiry (scratch) but may implicitly create temp files such as stderr, other FORTRAN temp files.

To correct for this try running your program from a different current directory then create your data file explicitly into the scratch folder.

Jim Dempsey


Thanks foryour response.

I am using Win XP, and the directory does not vanish even after quitting the application. When the program has tried to delete it and failed, if I try to delete it using Windows Explorer, I get a message that it is in use by another person or program and so cannot delete it. When I quit the program, I can then delete using Windows Explorer.

What the program does is to create a directory whose name is based on the name of a data file. It then reads a number of data block headers from the file and producesin the directorya set of dummy files whose names are based on the headers. An OpenFile Common Dialog Box is then used to select a header. Then I want to get rid of the directory and files. So all the files are of zero length and nothing is ever written to or from them.

It makes no difference if I create the files using a Fortran Open command or use the CreateFile WinAPI. Currently I am using the latter and closing the file handles before deleting the files - and I use a *.* type of delete, not just deleting the files I know about. I have tried using various Current Directories, but get no improvement.

What is seems to need is a "Let go of that Directory" command, but I don't know of one. Incidentally, if a directory is created without any files being put in it, there is no problem deleting it.

Any suggestions anyone?


Del *.* will not delete tentitive files. But I do not think this is the problem.

Experiment with this:

When you get to the point where you wish to delete the folder (i.e. after you think all the files in the folder have been deleted) then just prior to the delete call your OpenFile common dialog box and browse to a folder that is NOT the folder you wish to delete (or in the tree which is intended to be deleted). Then Cancel the Open file. i.e. get the OpenFile to move thecurrent directory.

If this works then figure out how to move the folder focus of OpenFile dlg without requiring this hack. This hack is only intended to help identify the problem.

Additionaly there might be some utility on that will track file opens/closes. Check out their website.

Jim Dempsey



Google search: open files

yields link to

This should help you.

Jim Dempsey


Thanks again.

Changing the OpenFile current directory did not work for me. BTW, I was using the DeleteFile API, but I am sure that the same holds for that. I will try looking at the link you suggest.



Be sure to follow-up with a post when you find and fix the problem. This information may help others.


I'm not sure how this ages old thread was revived, but anyway, here are my 2c...

By default, GetOpenFileName changes the current directory to the one you navigate to, unless you specify OFN_NOCHANGECURRENTDIR (or something like that). I guess that could be source of the system's complaint.

Process Explorer from SysInternals (which is also an excellent replacement for Task Manager) will tell you which process owns the file, but I guess it will be your process. You can check it yourself by calling GetCurrentDirectory.




I am having to give up on this one to get a job finished, but will post my findings positive or negative when I can get back to it.



Dear all,

my code (in raw FORTRAN) is executing other codes in temp directories. Then I collect the output and delete all the intermediate files. Now I would like to delete the temp folder as well. I receive the same error messages as you do. I've tried to change first to a folder different from the one being deleted. No way. In fact, even routines such as DELDIRQQ do not work.

Any suggestion? I am about to give up.

Best and thanks in advance,




What happens if you insert a break point (or PAUSE, or OK message box) just after the failingDELDIRQQ, and then (while application is running) manualy using Windows Explorer to delet the directory? Does it error or successfuly delete (or appear to successfuly delete)?

Jim Dempsey.

Leave a Comment

Please sign in to add a comment. Not a member? Join today