Hmm, I think I misunderstand the question but I'm going to risk it. What's wrong with the following straightforward method?
public static void CopyFilesRecursively(DirectoryInfo source, DirectoryInfo target) {
foreach (DirectoryInfo dir in source.GetDirectories())
CopyFilesRecursively(dir, target.CreateSubdirectory(dir.Name));
foreach (FileInfo file in source.GetFiles())
file.CopyTo(Path.Combine(target.FullName, file.Name));
}
EDIT Since this posting has garnered an impressive number of downvotes for such a simple answer to an equally simple question, let me add an explanation. Please read this before downvoting.
First of all, this code is not intendend as a drop-in replacement to the code in the question. It is for illustration purpose only.
Microsoft.VisualBasic.Devices.Computer.FileSystem.CopyDirectory
does some additional correctness tests (e.g. whether the source and target are valid directories, whether the source is a parent of the target etc.) that are missing from this answer. That code is probably also more optimized.
That said, the code works well. It has (almost identically) been used in a mature software for years. Apart from the inherent fickleness present with all IO handlings (e.g. what happens if the user manually unplugs the USB drive while your code is writing to it?), there are no known problems.
In particular, I’d like to point out that the use of recursion here is absolutely not a problem. Neither in theory (conceptually, it’s the most elegant solution) nor in practice: this code will not overflow the stack. The stack is large enough to handle even deeply nested file hierarchies. Long before stack space becomes a problem, the folder path length limitation kicks in.
Notice that a malicious user might be able to break this assumption by using deeply-nested directories of one letter each. I haven’t tried this. But just to illustrate the point: in order to make this code overflow on a typical computer, the directories would have to be nested a few thousand times. This is simply not a realistic scenario.
Microsoft.VisualBasic
is a bunch of add on stuff for making legacy VB6 projects easier to upgrade. You wouldn't normally use it in a C# application. If it was a 'proper' part of the .Net framework it would be inSystem.IO
. Also only theSystem.[something]
namespaces are part of Mono. – TeaselMicrosoft.VisualBasic
and notSystem.IO
? The reason it isn't in Mono is because all the libraries that are considered 'core' areSystem.[something]
- all the other ones are not. I've got no problem referencing an extra DLL, but there's a good reason why Microsoft haven't included this feature inSystem.IO
. – TeaselMicrosoft.VisualBasic
: would you be happy using a library from Perl in python? That's basically what's happening, with minor differences. Also, by not usingSystem.*
libraries, they are potentially constraining themselves from using Mono, which i gather may be a problem from the comments made by the OP. – CongratulantSystem.IO.Directory.Copy(sourceFolder, outputFolder)
– TeaselMicrosoft.VisualBasic.Devices
is not available in .NET core: github.com/dotnet/docs/issues/14546 – Pyroxene