我使用。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?

当前回答

在Windows资源管理器中选择路径或子文件夹似乎足以阻止目录的一次执行。Delete(path, true)，抛出如上所述的IOException和死亡，而不是引导Windows资源管理器到父文件夹并按预期进行。

2010-02-24 19:32:40

其他回答

我在特尔斐也遇到过同样的问题。最终的结果是我自己的应用程序锁定了我想要删除的目录。不知何故，当我写入目录(一些临时文件)时，目录被锁定了。

问题在于，在删除它之前，我对它的父目录做了一个简单的更改。

2008-11-30 21:02:27

你是否可能有一个竞争条件，另一个线程或进程正在向目录中添加文件:

顺序是:

删除进程A:

如果其他人在1和2之间添加了一个文件，那么2可能会抛出列出的异常?

2008-11-30 21:29:37

我很惊讶没有人想到这个简单的非递归方法，它可以删除包含只读文件的目录，而不需要更改每个文件的只读属性。

Process.Start("cmd.exe", "/c " + @"rmdir /s/q C:\Test\TestDirectoryContainingReadOnlyFiles");

(稍微改变一下，暂时不启动cmd窗口，这在互联网上都是可用的)

2012-06-02 05:54:17

您可以通过运行以下命令来重现错误:

Directory.CreateDirectory(@"C:\Temp\a\b\c\");
Process.Start(@"C:\Temp\a\b\c\");
Thread.Sleep(1000);
Directory.Delete(@"C:\Temp\a\b\c");
Directory.Delete(@"C:\Temp\a\b");
Directory.Delete(@"C:\Temp\a");

当试图删除目录'b'时，它抛出IOException“目录不是空的”。这很愚蠢，因为我们刚刚删除了目录'c'。

在我的理解中，解释是目录'c'被标记为已删除。但是系统中还没有提交删除操作。系统已经回复任务已经完成，而实际上它还在处理中。系统可能会等待文件资源管理器已经关注到父目录才提交删除。

如果你查看删除函数(http://referencesource.microsoft.com/#mscorlib/system/io/directory.cs)的源代码，你会发现它使用本机Win32Native。RemoveDirectory函数。这种不等待行为在这里被注意到:

RemoveDirectory函数在关闭时标记要删除的目录。因此，直到关闭该目录的最后一个句柄，才会删除该目录。

(http://msdn.microsoft.com/en-us/library/windows/desktop/aa365488 (v = vs.85) . aspx)

休眠和重试是解决方案。参考ryascl的溶液。

2014-09-05 08:06:12

我在使用TFS2012的构建服务器上使用Windows Workflow Foundation时遇到过同样的问题。在内部，工作流调用Directory.Delete()并将递归标志设置为true。在我们的案例中，这似乎与网络有关。

在用最新的二进制文件重新创建和重新填充网络共享上的二进制文件之前，我们正在删除它。其他的构建都会失败。在构建失败后打开删除文件夹时，文件夹为空，这表明directory. delete()调用的每个方面都是成功的，除了删除实际的目录。

这个问题似乎是由网络文件通信的异步特性引起的。构建服务器告诉文件服务器删除所有文件，文件服务器报告它已经删除了，即使它还没有完全完成。然后构建服务器请求删除目录，而文件服务器拒绝了该请求，因为它还没有完全完成文件的删除。

在我们的案例中有两个可能的解决方案:

在我们自己的代码中建立递归删除，每个步骤之间都有延迟和验证在IOException发生后重试最多X次，在再次尝试之前给予延迟

后一种方法又快又脏，但似乎很管用。

2013-07-24 15:28:43

不能使用目录删除目录。删除(路径,真的)

推荐文章

最新文章

标签