如标题所示，在system.io的directory类中有一个directory.move，但没有Directory.Copy方法。有什么原因吗？

更新：

对我来说，复制和移动操作几乎完全相同，唯一的区别是移动操作执行复制，然后删除目标。错误处理对于move和copy同样复杂。那么，如果一个被实现了，为什么另一个没有实现呢？

更新2：

这是来自mmclean评论的引用：

Directory.Move however does not move, it renames. Thus the
"destination" path is a full path to point to the directory, rather
than a location to"move into", and moving to a different drive is
impossible.

号

所以我理解move实际上执行一个重命名操作(只更改文件分配表中的条目)。但move和copy命令在合并目标中现有的项时都有相同的问题(覆盖/保留这两者)。因此，复制操作唯一增加的复杂性是它必须物理地复制周围的文件。但这仍然不能解释不执行这一决定的原因。更重要的是，当copy命令在vb.net中实现，并且这里有一个在msdn上进行复制操作的非常简单的实现。

实际的答案是没有Windows API调用来复制目录，而有Windows API调用来移动(也称为重命名)目录(MoveFile())。

Directory.Move()称MoveFile()为其实施的一部分。但是没有什么可以要求复制的。

它们似乎保持了与WindowsAPI提供的界面大致相似的界面。

此外，对于失败的目录复制的错误处理非常糟糕。是否必须回滚任何更改？如何处理失败的拷贝将是如此依赖于上下文，以至于很难使用通用方法。这可能就是为什么没有Windows API调用来复制目录的原因。

另一个可能导致增加复杂性的因素是在复制过程中锁定不同的文件，以及在复制过程中从目录中添加和删除文件。

(尽管在这里的另一个答案中提到，有一个VisualBasic方法来复制目录，它必须解决其中的一些问题。)

与其问为什么，不如使用vb.net的CopyDirectoryhttp://msdn.microsoft.com/en-us/library/microsoft.visualbasic.fileio.filesystem.copydirectory.aspx。

您希望Directory.Copy()方法做什么？

这并不明显，至少有3个明确的选择：

• 创建1个同名的新空目录
• 复制所有子目录
• 复制所有子目录和所有文件

虽然这三种语言在某个时候都可以使用，但是程序员不会立即从名称中知道所期望的是什么。提供这种功能只会造成混乱。

第一个很难用，它是另一个名称的create()。最后2个比较昂贵，需要一些选项来定制行为。

你可以自己写，但不要使用Copy()这个名字。以Directory.CloneEmptyFolders()和Directory.CloneFoldersWithFiles()为例