我使用。net 3.5，试图递归删除目录使用:
Directory.Delete(myPath, true);
我的理解是，如果文件正在使用或存在权限问题，这应该抛出，但否则它应该删除目录及其所有内容。
然而，我偶尔会遇到这样的情况:
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)
...
我并不惊讶于这个方法有时会抛出错误，但我惊讶于当递归为真时得到这个特定的消息。(我知道目录不是空的。)
是否有一个原因，我将看到这个而不是AccessViolationException?
我在使用TFS2012的构建服务器上使用Windows Workflow Foundation时遇到过同样的问题。在内部，工作流调用Directory.Delete()并将递归标志设置为true。在我们的案例中，这似乎与网络有关。
在用最新的二进制文件重新创建和重新填充网络共享上的二进制文件之前，我们正在删除它。其他的构建都会失败。在构建失败后打开删除文件夹时，文件夹为空，这表明directory. delete()调用的每个方面都是成功的，除了删除实际的目录。
这个问题似乎是由网络文件通信的异步特性引起的。构建服务器告诉文件服务器删除所有文件，文件服务器报告它已经删除了，即使它还没有完全完成。然后构建服务器请求删除目录，而文件服务器拒绝了该请求，因为它还没有完全完成文件的删除。
在我们的案例中有两个可能的解决方案:
在我们自己的代码中建立递归删除，每个步骤之间都有延迟和验证
在IOException发生后重试最多X次，在再次尝试之前给予延迟
后一种方法又快又脏，但似乎很管用。
如上所述，“可接受的”解决方案在重解析点上失败。
有一个更短的解决方案可以正确地复制功能:
public static void rmdir(string target, bool recursive)
{
string tfilename = Path.GetDirectoryName(target) +
(target.Contains(Path.DirectorySeparatorChar.ToString()) ? Path.DirectorySeparatorChar.ToString() : string.Empty) +
Path.GetRandomFileName();
Directory.Move(target, tfilename);
Directory.Delete(tfilename, recursive);
}
我知道，不能处理后面提到的权限情况，但是FAR BETTER提供了原始/stock Directory.Delete()的预期功能，而且代码也少得多。
您可以安全地进行处理，因为旧的dir将被清除……即使没有消失，因为“文件系统仍在追赶”(或任何借口，微软提供了一个坏的功能)。
作为一个好处，如果你知道你的目标目录是大/深的，并且不想等待(或麻烦的异常)，最后一行可以替换为:
ThreadPool.QueueUserWorkItem((o) => { Directory.Delete(tfilename, recursive); });
你仍然可以安全地继续工作。
