I'm using .NET 3.5, trying to recursively delete a directory using:
Directory.Delete(myPath, true);
My understanding is that this should throw if files are in use or there is a permissions problem, but otherwise it should delete the directory and all of its contents.
However, I occasionally get this:
System.IO.IOException: The directory is not empty.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive)
at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive)
...
I'm not surprised that the method sometimes throws, but I'm surprised to get this particular message when recursive is true. (I know the directory is not empty.)
Is there a reason I'd see this instead of AccessViolationException?
This answer is based on: https://stackoverflow.com/a/1703799/184528. The difference with my code, is that we only recurse many delete sub-directories and files when necessary a call to Directory.Delete fails on a first attempt (which can happen because of windows explorer looking at a directory).
If your application's (or any other application's) current directory is the one you're trying to delete, it will not be an access violation error but a directory is not empty. Make sure it's not your own application by changing the current directory; also, make sure the directory is not open in some other program (e.g. Word, excel, Total Commander, etc.). Most programs will cd to the directory of the last file opened, which would cause that.
I think that there is a file open by some stream you are not aware of I had the same problem and solved it by closing all the streams that where pointing to the directory I wanted to delete.
This error occurs if any file or directory is considered in-use. It is a misleading error. Check to see if you have any explorer windows or command-line windows open to any directory in the tree, or a program that is using a file in that tree.
I´ve solved with this millenary technique (you can leave the Thread.Sleep on his own in the catch)