Хм, я думаю, що я неправильно розумію це питання, але збираюся ризикувати. Що не так із наступним простим методом?
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 Оскільки ця публікація набрала вражаючу кількість записів для такої простої відповіді на не менш просте запитання, дозвольте додати пояснення. Будь ласка, прочитайте це перед тим, як відмовитись .
Перш за все, цей код не є наміром, як заміною коду у питанні. Це лише для ілюстрації.
Microsoft.VisualBasic.Devices.Computer.FileSystem.CopyDirectory
робить деякі додаткові тести на правильність (наприклад, чи джерело та ціль є дійсними каталогами, чи джерело є батьком цілі тощо), які відсутні у цій відповіді. Цей код, ймовірно, також більш оптимізований.
Однак, код працює добре . Він має (майже однаково) був використаний в зрілому програмному забезпеченні в протягом багатьох років. Крім притаманної нестабільності, яка присутня у всіх обробках IO (наприклад, що відбувається, якщо користувач вручну відключить USB-накопичувач, поки ваш код пише на нього?), Немає відомих проблем.
Зокрема, я хотів би зазначити, що використання рекурсії тут абсолютно не є проблемою. Ні в теорії (концептуально це найелегантніше рішення), ні на практиці: цей код не переповнить стек . Стек достатньо великий для обробки навіть глибоко вкладених ієрархій файлів. Задовго до того, як простір стека стане проблемою, починається обмеження довжини шляху папки.
Зауважте, що зловмисний користувач міг би зламати це припущення, використовуючи глибоко вкладені каталоги по одній букві кожен. Я цього не пробував. Але лише для того, щоб проілюструвати суть: для того, щоб цей код переповнювався на типовому комп'ютері, каталоги повинні були вкладатись у кілька тисяч разів. Це просто не реалістичний сценарій.