Hmm, chyba nie rozumiem pytania, ale zaryzykuję. Co jest nie tak z następującą prostą metodą?
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));
}
EDYCJA Ponieważ ten post zebrał imponującą liczbę głosów negatywnych za tak prostą odpowiedź na równie proste pytanie, pozwól mi dodać wyjaśnienie. Proszę przeczytać przed downvoting .
Przede wszystkim ten kod nie jest zamiennikiem zastępującym kod w pytaniu. To jest wyłącznie w celach ilustracyjnych.
Microsoft.VisualBasic.Devices.Computer.FileSystem.CopyDirectory
wykonuje dodatkowe testy poprawności (np. czy źródło i cel są poprawnymi katalogami, czy źródło jest rodzicem celu itp.), których brakuje w tej odpowiedzi. Ten kod jest prawdopodobnie również bardziej zoptymalizowany.
To powiedziawszy, kod działa dobrze . To jest (prawie identycznie) zostały wykorzystane w dojrzałym oprogramowania przez lata. Oprócz nieodłącznej zmienności występującej we wszystkich operacjach we / wy (np. Co się stanie, jeśli użytkownik ręcznie odłączy dysk USB podczas pisania na nim kodu?), Nie ma znanych problemów.
W szczególności chciałbym zwrócić uwagę, że zastosowanie rekurencji tutaj absolutnie nie stanowi problemu. Ani w teorii (koncepcyjnie jest to najbardziej eleganckie rozwiązanie), ani w praktyce: ten kod nie przepełni stosu . Stos jest wystarczająco duży, aby obsłużyć nawet głęboko zagnieżdżone hierarchie plików. Na długo przed pojawieniem się problemu ze stosem zaczyna się ograniczenie długości ścieżki folderu.
Zauważ, że złośliwy użytkownik może złamać to założenie, używając głęboko zagnieżdżonych katalogów po jednej literze. Nie próbowałem tego. Ale żeby to zilustrować: aby przepełnić ten kod na typowym komputerze, katalogi musiałyby być zagnieżdżone kilka tysięcy razy. To po prostu nie jest realistyczny scenariusz.