Я использую .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?

Примечание редактора: хотя этот ответ содержит некоторую полезную информацию, он фактически неверен в отношении работы Directory.Delete. Пожалуйста, прочитайте комментарии к этому ответу и другие ответы на этот вопрос.

Я столкнулся с этой проблемой раньше.

Корень проблемы в том, что эта функция не удаляет файлы, которые находятся в структуре каталогов. Поэтому вам нужно создать функцию, которая удаляет все файлы в структуре каталогов, а затем все каталоги, прежде чем удалять сам каталог. Я знаю, что это идет против второго параметра, но это гораздо более безопасный подход. Кроме того, вы, вероятно, захотите удалить атрибуты доступа READ-ONLY из файлов непосредственно перед их удалением. В противном случае это вызовет исключение.

Просто вставьте этот код в свой проект.

public static void DeleteDirectory(string target_dir)
{
    string[] files = Directory.GetFiles(target_dir);
    string[] dirs = Directory.GetDirectories(target_dir);

    foreach (string file in files)
    {
        File.SetAttributes(file, FileAttributes.Normal);
        File.Delete(file);
    }

    foreach (string dir in dirs)
    {
        DeleteDirectory(dir);
    }

    Directory.Delete(target_dir, false);
}

Кроме того, я лично добавляю ограничение на области машины, которые разрешено удалять, потому что вы хотите, чтобы кто-то вызывал эту функцию C:\WINDOWS (%WinDir%)или C:\.

Если вы пытаетесь рекурсивно удалить каталог, aи каталог a\bоткрыт в проводнике, bон будет удален, но вы получите сообщение об ошибке «каталог не пустой», aдаже если он пуст, когда вы идете и смотрите. Текущий каталог любого приложения (включая Проводник) сохраняет дескриптор каталога . Когда вы звоните Directory.Delete(true), он удаляет снизу вверх:, bзатем a. Если bон открыт в Explorer, Explorer обнаружит удаление b, поменяет каталог вверх cd ..и очистит открытые дескрипторы. Поскольку файловая система работает асинхронно, Directory.Deleteоперация завершается ошибкой из-за конфликтов с проводником.

Неполное решение

Первоначально я опубликовал следующее решение с идеей прерывания текущего потока, чтобы у проводника было время освободить дескриптор каталога.

// incomplete!
try
{
    Directory.Delete(path, true);
}
catch (IOException)
{
    Thread.Sleep(0);
    Directory.Delete(path, true);
}

Но это работает, только если открытый каталог является непосредственным дочерним элементом удаляемого каталога. Если a\b\c\dон открыт в Проводнике, и вы используете его a, этот метод завершится ошибкой после удаления dи c.

Несколько лучшее решение

Этот метод будет обрабатывать удаление глубокой структуры каталогов, даже если в Проводнике открыт один из каталогов нижнего уровня.

/// <summary>
/// Depth-first recursive delete, with handling for descendant 
/// directories open in Windows Explorer.
/// </summary>
public static void DeleteDirectory(string path)
{
    foreach (string directory in Directory.GetDirectories(path))
    {
        DeleteDirectory(directory);
    }

    try
    {
        Directory.Delete(path, true);
    }
    catch (IOException) 
    {
        Directory.Delete(path, true);
    }
    catch (UnauthorizedAccessException)
    {
        Directory.Delete(path, true);
    }
}

Несмотря на дополнительную работу по возврату данных самостоятельно, мы все еще должны справиться с тем, UnauthorizedAccessExceptionчто может произойти на этом пути. Неясно, прокладывает ли первая попытка удаления вторую, удачную, или это просто временная задержка, вызванная выбросом / перехватом исключения, которое позволяет файловой системе наверстать упущенное.

Возможно, вы сможете уменьшить количество исключений, генерируемых и перехваченных в типичных условиях, добавляя Thread.Sleep(0)в начале tryблока. Кроме того, существует риск того, что при большой загрузке системы вы можете выполнить обе Directory.Deleteпопытки и потерпеть неудачу. Считайте это решение отправной точкой для более надежного рекурсивного удаления.

Общий ответ

Это решение касается только особенностей взаимодействия с Windows Explorer. Если вам нужна надежная операция удаления, следует помнить, что все (антивирусный сканер и т. Д.) Может иметь открытый дескриптор того, что вы пытаетесь удалить, в любое время. Поэтому вы должны попробовать позже. Сколько позже и сколько раз вы попробуете, зависит от того, насколько важно удалить объект. Как указывает MSDN ,

Надежный файловый итерационный код должен учитывать многие сложности файловой системы.

Это невинное утверждение, снабженное только ссылкой на справочную документацию NTFS, должно заставить ваши волосы встать на ноги.

( Изменить : много. Первоначально у этого ответа было только первое, неполное решение.)

Прежде чем идти дальше, проверьте следующие причины, которые находятся под вашим контролем:

• Папка установлена ​​как текущая директория вашего процесса? Если да, сначала измените его на что-то другое.
• Вы открыли файл (или загрузили DLL) из этой папки? (и забыл закрыть / разгрузить его)

В противном случае проверьте следующие законные причины вне вашего контроля:

• В этой папке есть файлы, помеченные как доступные только для чтения.
• У вас нет разрешения на удаление некоторых из этих файлов.
• Файл или подпапка открыта в Проводнике или другом приложении.

Если что-то из перечисленного является проблемой, вы должны понять, почему это происходит, прежде чем пытаться улучшить свой код удаления. Должно ли ваше приложение удалять файлы только для чтения или недоступные файлы? Кто так их пометил и почему?

Как только вы исключили вышеуказанные причины, все еще существует вероятность ложных сбоев. Удаление не удастся, если кто-то держит дескриптор любого из удаляемых файлов или папок, и существует множество причин, по которым кто-то может перечислять папку или читать ее файлы:

• поисковые индексы
• антивирусы
• программное обеспечение для резервного копирования

Общий подход к устранению ложных сбоев состоит в том, чтобы делать попытки несколько раз, делая паузу между попытками. Вы, очевидно, не хотите продолжать попытки вечно, поэтому вам следует отказаться после определенного количества попыток и либо выбросить исключение, либо проигнорировать ошибку. Нравится:

private static void DeleteRecursivelyWithMagicDust(string destinationDir) {
    const int magicDust = 10;
    for (var gnomes = 1; gnomes <= magicDust; gnomes++) {
        try {
            Directory.Delete(destinationDir, true);
        } catch (DirectoryNotFoundException) {
            return;  // good!
        } catch (IOException) { // System.IO.IOException: The directory is not empty
            System.Diagnostics.Debug.WriteLine("Gnomes prevent deletion of {0}! Applying magic dust, attempt #{1}.", destinationDir, gnomes);

            // see http://stackoverflow.com/questions/329355/cannot-delete-directory-with-directory-deletepath-true for more magic
            Thread.Sleep(50);
            continue;
        }
        return;
    }
    // depending on your use case, consider throwing an exception here
}

На мой взгляд, такой помощник должен использоваться для всех удалений, потому что ложные сбои всегда возможны. Однако ВЫ ДОЛЖНЫ ПРИНЯТЬ ЭТОТ КОД К ВАШЕМУ ИСПОЛЬЗОВАНИЮ, а не просто слепо копировать его.

У меня были ложные сбои для внутренней папки данных, созданной моим приложением, расположенной в папке% LocalAppData%, поэтому мой анализ выглядит следующим образом:

1. Папка управляется исключительно моим приложением, и у пользователя нет веской причины для того, чтобы отмечать вещи как доступные только для чтения или недоступные в этой папке, поэтому я не пытаюсь разобраться с этим случаем.

2. Там нет ценного пользовательского материала, поэтому нет риска принудительного удаления чего-либо по ошибке.

3. Будучи внутренней папкой данных, я не ожидаю, что она будет открыта в проводнике, по крайней мере, я не чувствую необходимости конкретно обрабатывать дело (т.е. я прекрасно справляюсь с этим делом через службу поддержки).

4. Если все попытки не удаются, я предпочитаю игнорировать ошибку. В худшем случае приложение не может распаковать некоторые новые ресурсы, вылетает и предлагает пользователю обратиться в службу поддержки, что является приемлемым для меня, если это происходит не часто. Или, если приложение не аварийно завершает работу, оно оставляет некоторые старые данные, что опять-таки приемлемо для меня.

5. Я решил ограничить количество попыток до 500 мс (50 * 10). Это произвольный порог, который работает на практике; Я хотел, чтобы порог был достаточно коротким, чтобы пользователи не убивали приложение, думая, что оно перестало отвечать. С другой стороны, полсекунды - это достаточно времени, чтобы нарушитель мог закончить обработку моей папки. Судя по другим ответам SO, которые иногда даже Sleep(0)приемлемы, очень немногие пользователи когда-либо будут испытывать больше, чем одна повторная попытка.

6. Я повторяю каждые 50 мс, что является другим произвольным числом. Я чувствую, что если файл обрабатывается (индексируется, проверяется), когда я пытаюсь удалить его, 50 мс - это подходящее время, чтобы ожидать завершения обработки в моем случае. Кроме того, 50 мс достаточно мал, чтобы не привести к заметному замедлению; опять же, Sleep(0)кажется, этого достаточно во многих случаях, поэтому мы не хотим слишком долго откладывать.

7. Код повторяется при любых исключениях ввода-вывода. Обычно я не ожидаю каких-либо исключений при доступе к% LocalAppData%, поэтому я выбрал простоту и принял риск задержки в 500 мс в случае легитимного исключения. Я также не хотел придумывать способ обнаружить точное исключение, к которому я хочу повторить попытку.

Современный асинхронный ответ

Принятый ответ просто неверен, он может сработать для некоторых людей, потому что время, необходимое для получения файлов с диска, освобождает все, что блокировало файлы. Дело в том, что это происходит потому, что файлы блокируются каким-либо другим процессом / потоком / действием. Другие ответы используют Thread.Sleep(Yuck), чтобы через некоторое время повторить попытку удаления каталога. Этот вопрос нуждается в повторении с более современным ответом.

public static async Task<bool> TryDeleteDirectory(
   string directoryPath,
   int maxRetries = 10,
   int millisecondsDelay = 30)
{
    if (directoryPath == null)
        throw new ArgumentNullException(directoryPath);
    if (maxRetries < 1)
        throw new ArgumentOutOfRangeException(nameof(maxRetries));
    if (millisecondsDelay < 1)
        throw new ArgumentOutOfRangeException(nameof(millisecondsDelay));

    for (int i = 0; i < maxRetries; ++i)
    {
        try
        {
            if (Directory.Exists(directoryPath))
            {
                Directory.Delete(directoryPath, true);
            }

            return true;
        }
        catch (IOException)
        {
            await Task.Delay(millisecondsDelay);
        }
        catch (UnauthorizedAccessException)
        {
            await Task.Delay(millisecondsDelay);
        }
    }

    return false;
}

Модульные тесты

Эти тесты показывают пример того, как заблокированный файл может привести Directory.Deleteк сбою, и TryDeleteDirectoryспособ, описанный выше, устраняет проблему.

[Fact]
public async Task TryDeleteDirectory_FileLocked_DirectoryNotDeletedReturnsFalse()
{
    var directoryPath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
    var subDirectoryPath = Path.Combine(Path.GetTempPath(), "SubDirectory");
    var filePath = Path.Combine(directoryPath, "File.txt");

    try
    {
        Directory.CreateDirectory(directoryPath);
        Directory.CreateDirectory(subDirectoryPath);

        using (var fileStream = new FileStream(filePath, FileMode.Create, FileAccess.Write, FileShare.Write))
        {
            var result = await TryDeleteDirectory(directoryPath, 3, 30);
            Assert.False(result);
            Assert.True(Directory.Exists(directoryPath));
        }
    }
    finally
    {
        if (Directory.Exists(directoryPath))
        {
            Directory.Delete(directoryPath, true);
        }
    }
}

[Fact]
public async Task TryDeleteDirectory_FileLockedThenReleased_DirectoryDeletedReturnsTrue()
{
    var directoryPath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
    var subDirectoryPath = Path.Combine(Path.GetTempPath(), "SubDirectory");
    var filePath = Path.Combine(directoryPath, "File.txt");

    try
    {
        Directory.CreateDirectory(directoryPath);
        Directory.CreateDirectory(subDirectoryPath);

        Task<bool> task;
        using (var fileStream = new FileStream(filePath, FileMode.Create, FileAccess.Write, FileShare.Write))
        {
            task = TryDeleteDirectory(directoryPath, 3, 30);
            await Task.Delay(30);
            Assert.True(Directory.Exists(directoryPath));
        }

        var result = await task;
        Assert.True(result);
        Assert.False(Directory.Exists(directoryPath));
    }
    finally
    {
        if (Directory.Exists(directoryPath))
        {
            Directory.Delete(directoryPath, true);
        }
    }
}

Одна важная вещь, о которой следует упомянуть (я добавил ее в качестве комментария, но мне не разрешено), это то, что поведение перегрузки изменилось с .NET 3.5 на .NET 4.0.

Directory.Delete(myPath, true);

Начиная с .NET 4.0 он удаляет файлы в самой папке, но НЕ в 3.5. Это можно увидеть и в документации MSDN.

.NET 4.0

Удаляет указанный каталог и, если указано, любые подкаталоги и файлы в каталоге.

.NET 3.5

Удаляет пустой каталог и, если указано, любые подкаталоги и файлы в каталоге.

У меня была та же проблема под Delphi. И в результате мое приложение блокировало каталог, который я хотел удалить. Каким-то образом каталог был заблокирован, когда я писал в него (некоторые временные файлы).

Уловка 22 состояла в том, что я сделал простую замену каталога на его родительский, прежде чем удалить его.

Я удивлен, что никто не думал об этом простом нерекурсивном методе, который может удалять каталоги, содержащие файлы только для чтения, без необходимости изменять атрибут «только чтение» каждого из них.

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

(Измените немного, чтобы не запускать окно cmd на мгновение, которое доступно по всему интернету)

Вы можете воспроизвести ошибку, запустив:

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» помечается как удаленный. Но удаление еще не зафиксировано в системе. Система ответила, что работа выполнена, хотя на самом деле она все еще обрабатывается. Система, вероятно, ожидает, что файловый менеджер сосредоточится на родительском каталоге, чтобы зафиксировать удаление.

Если вы посмотрите на исходный код функции Delete ( 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 )

Сон и повторите это решение. См. Решение Ряскля.

У меня были странные проблемы с разрешением на удаление каталогов профилей пользователей (в C: \ Documents and Settings), несмотря на то, что я мог это делать в оболочке Explorer.

File.SetAttributes(target_dir, FileAttributes.Normal);
Directory.Delete(target_dir, false);

Мне не имеет смысла, что «файловая» операция делает с каталогом, но я знаю, что она работает, и этого мне достаточно!

Этот ответ основан на: https://stackoverflow.com/a/1703799/184528 . Разница с моим кодом заключается в том, что мы возвращаем много удаленных подкаталогов и файлов только при необходимости, вызов Directory.Delete завершается неудачно с первой попытки (что может произойти из-за того, что проводник Windows просматривает каталог).

    public static void DeleteDirectory(string dir, bool secondAttempt = false)
    {
        // If this is a second try, we are going to manually 
        // delete the files and sub-directories. 
        if (secondAttempt)
        {
            // Interrupt the current thread to allow Explorer time to release a directory handle
            Thread.Sleep(0);

            // Delete any files in the directory 
            foreach (var f in Directory.GetFiles(dir, "*.*", SearchOption.TopDirectoryOnly))
                File.Delete(f);

            // Try manually recursing and deleting sub-directories 
            foreach (var d in Directory.GetDirectories(dir))
                DeleteDirectory(d);

            // Now we try to delete the current directory
            Directory.Delete(dir, false);
            return;
        }

        try
        {
            // First attempt: use the standard MSDN approach.
            // This will throw an exception a directory is open in explorer
            Directory.Delete(dir, true);
        }
        catch (IOException)
        {
            // Try again to delete the directory manually recursing. 
            DeleteDirectory(dir, true);
        }
        catch (UnauthorizedAccessException)
        {
            // Try again to delete the directory manually recursing. 
            DeleteDirectory(dir, true);
        } 
    }

Ни одно из перечисленных выше решений не помогло мне. В итоге я использовал отредактированную версию решения @ryascl, как показано ниже:

    /// <summary>
    /// Depth-first recursive delete, with handling for descendant 
    /// directories open in Windows Explorer.
    /// </summary>
    public static void DeleteDirectory(string path)
    {
        foreach (string directory in Directory.GetDirectories(path))
        {
            Thread.Sleep(1);
            DeleteDir(directory);
        }
        DeleteDir(path);
    }

    private static void DeleteDir(string dir)
    {
        try
        {
            Thread.Sleep(1);
            Directory.Delete(dir, true);
        }
        catch (IOException)
        {
            DeleteDir(dir);
        }
        catch (UnauthorizedAccessException)
        {
            DeleteDir(dir);
        }
    }

Возможно ли, что у вас есть состояние гонки, когда другой поток или процесс добавляет файлы в каталог:

Последовательность будет:

Процесс удаления А:

1. Очистить каталог
2. Удалить (теперь пустой) каталог.

Если кто-то еще добавит файл между 1 и 2, тогда, возможно, 2 выдаст исключение из списка?

Я потратил несколько часов, чтобы решить эту проблему и другие исключения с удалением каталога. Это мое решение

 public static void DeleteDirectory(string target_dir)
    {
        DeleteDirectoryFiles(target_dir);
        while (Directory.Exists(target_dir))
        {
            lock (_lock)
            {
                DeleteDirectoryDirs(target_dir);
            }
        }
    }

    private static void DeleteDirectoryDirs(string target_dir)
    {
        System.Threading.Thread.Sleep(100);

        if (Directory.Exists(target_dir))
        {

            string[] dirs = Directory.GetDirectories(target_dir);

            if (dirs.Length == 0)
                Directory.Delete(target_dir, false);
            else
                foreach (string dir in dirs)
                    DeleteDirectoryDirs(dir);
        }
    }

    private static void DeleteDirectoryFiles(string target_dir)
    {
        string[] files = Directory.GetFiles(target_dir);
        string[] dirs = Directory.GetDirectories(target_dir);

        foreach (string file in files)
        {
            File.SetAttributes(file, FileAttributes.Normal);
            File.Delete(file);
        }

        foreach (string dir in dirs)
        {
            DeleteDirectoryFiles(dir);
        }
    }

Этот код имеет небольшую задержку, которая не важна для моего приложения. Но будьте осторожны, задержка может быть проблемой для вас, если у вас есть много подкаталогов в каталоге, который вы хотите удалить.

Рекурсивное удаление каталогов, которое не удаляет файлы, безусловно, неожиданно. Мое исправление для этого:

public class IOUtils
{
    public static void DeleteDirectory(string directory)
    {
        Directory.GetFiles(directory, "*", SearchOption.AllDirectories).ForEach(File.Delete);
        Directory.Delete(directory, true);
    }
}

Я сталкивался с случаями, когда это помогало, но, как правило, Directory.Delete удаляет файлы внутри каталогов после рекурсивного удаления, как описано в msdn .

Время от времени я сталкиваюсь с этим нерегулярным поведением также как пользователь Windows Explorer: иногда я не могу удалить папку (она думает, что бессмысленное сообщение «отказано в доступе»), но когда я развертываю и удаляю нижние элементы, я могу удалить верхние предметы также. Поэтому я думаю, что приведенный выше код имеет дело с аномалией ОС, а не с проблемой библиотеки базовых классов.

Каталог или файл в нем заблокированы и не могут быть удалены. Найдите виновника, который его запирает, и посмотрите, сможете ли вы его устранить.

Похоже, что выбор пути или подпапки в проводнике Windows достаточен, чтобы заблокировать одиночное выполнение Directory.Delete (path, true), выбрасывая IOException, как описано выше, и умирая вместо загрузки Windows Explorer из родительской папки и действуя как ожидается.

У меня была эта проблема сегодня. Это происходило потому, что у меня был проводник Windows, открытый для каталога, который пытался удалить, вызывая рекурсивный вызов сбой и, следовательно, IOException. Убедитесь, что в каталоге нет ручек.

Кроме того, в MSDN ясно, что вам не нужно писать собственный отзыв: http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx

У меня была такая же проблема с Windows Workflow Foundation на сервере сборки с TFS2012. Внутренне рабочий процесс называется Directory.Delete () с рекурсивным флагом, установленным в true. В нашем случае это связано с сетью.

Мы удаляли двоичную папку для отбрасывания на общем сетевом ресурсе, а затем заново создавали и заново заполняли ее последними двоичными файлами. Любая другая сборка потерпит неудачу. При открытии папки удаления после неудачной сборки папка была пустой, что указывает на то, что все аспекты вызова Directory.Delete () были успешными, за исключением удаления действительного каталога.

Похоже, что проблема вызвана асинхронным характером обмена файлами по сети. Сервер сборки приказал файловому серверу удалить все файлы, а файловый сервер сообщил, что это произошло, хотя он еще не был полностью завершен. Затем сервер сборки запросил удаление каталога, а файловый сервер отклонил запрос, потому что он не завершил удаление файлов.

Два возможных решения в нашем случае:

• Создайте рекурсивное удаление в нашем собственном коде с задержками и проверками между каждым шагом
• Повторите попытку до X раз после IOException, давая задержку перед повторной попыткой

Последний метод быстрый и грязный, но, кажется, делает свое дело.

Это из-за FileChangesNotifications.

Это происходит начиная с ASP.NET 2.0. Когда вы удаляете какую-либо папку в приложении, она перезапускается . Вы можете увидеть это сами, используя ASP.NET Health Monitoring .

Просто добавьте этот код в ваш web.config / configuration / system.web:

<healthMonitoring enabled="true">
  <rules>
    <add name="MyAppLogEvents" eventName="Application Lifetime Events" provider="EventLogProvider" profile="Critical"/>
  </rules>
</healthMonitoring>

После этого проверьте Windows Log -> Application. Что здесь происходит:

При удалении папки, если есть Delete(path, true)подпапка, сначала удаляется подпапка. FileChangesMonitor достаточно знать об удалении и закрыть ваше приложение. Между тем ваш основной каталог еще не удален. Это событие из журнала:

Delete() не закончил свою работу, и, поскольку приложение закрывается, возникает исключение:

Если у вас нет подпапок в папке, которую вы удаляете, Delete () просто удаляет все файлы и эту папку, приложение тоже перезапускается, но вы не получаете никаких исключений , потому что перезапуск приложения ничего не прерывает. Но все равно вы теряете все внутрипроцессные сеансы, приложение не отвечает на запросы при перезапуске и т. Д.

Что теперь?

Существуют некоторые обходные пути и твики для отключения этого поведения, « Соединение каталогов» , « Отключение FCN с реестром» , « Остановка FileChangesMonitor с помощью Reflection» (поскольку нет открытого метода) , но все они, похоже, не правы, поскольку FCN существует для причина. Он следит за структурой вашего приложения , которая не является структурой ваших данных . Краткий ответ: разместите папки, которые вы хотите удалить за пределами вашего приложения. FileChangesMonitor не будет получать уведомлений, и ваше приложение не будет перезапускаться каждый раз. Вы не получите никаких исключений. Чтобы сделать их видимыми из Интернета, есть два способа:

1. Создайте контроллер, который обрабатывает входящие вызовы, а затем отправляет файлы обратно, читая из папки вне приложения (вне wwwroot).

2. Если ваш проект большой и производительность важнее всего, создайте отдельный маленький и быстрый веб-сервер для обслуживания статического контента. Таким образом вы оставите IIS свою конкретную работу. Это может быть на той же машине (mongoose для Windows) или на другой машине (nginx для Linux). Хорошей новостью является то, что вам не нужно платить дополнительную лицензию Microsoft для установки статического сервера контента в Linux.

Надеюсь это поможет.

Как упомянуто выше, «принятое» решение терпит неудачу в точках повторного анализа - но люди все еще отмечают его (???) Существует гораздо более короткое решение, которое правильно копирует функциональность:

public static void rmdir(string target, bool recursive)
{
    string tfilename = Path.GetDirectoryName(target) +
        (target.Contains(Path.DirectorySeparatorChar.ToString()) ? Path.DirectorySeparatorChar.ToString() : string.Empty) +
        Path.GetRandomFileName();
    Directory.Move(target, tfilename);
    Directory.Delete(tfilename, recursive);
}

Я знаю, что не обрабатывает случаи разрешений, упомянутые позже, но для всех целей и задач FAR BETTER обеспечивает ожидаемую функциональность оригинального / стокового Directory.Delete () - и с гораздо меньшим количеством кода тоже .

Вы можете безопасно продолжить обработку, потому что старый каталог будет в стороне … даже если он не исчезнет, ​​потому что «файловая система все еще догоняет» (или любое другое оправдание, которое MS дал для предоставления сломанной функции) .

В качестве преимущества, если вы знаете, что целевой каталог большой / глубокий и не хотите ждать (или беспокоиться об исключениях), последнюю строку можно заменить на:

    ThreadPool.QueueUserWorkItem((o) => { Directory.Delete(tfilename, recursive); });

Вы все еще можете продолжать работать.

Эта проблема может возникать в Windows, когда в каталоге (или в любом подкаталоге) есть файлы, длина пути которых превышает 260 символов.

В таких случаях вам нужно удалить \\\\?\C:\mydirвместо C:\mydir. О пределе в 260 символов вы можете прочитать здесь .

Я решил с этой техникой тысячелетия (вы можете оставить Thread.Sleep самостоятельно в улове)

bool deleted = false;
        do
        {
            try
            {
                Directory.Delete(rutaFinal, true);                    
                deleted = true;
            }
            catch (Exception e)
            {
                string mensaje = e.Message;
                if( mensaje == "The directory is not empty.")
                Thread.Sleep(50);
            }
        } while (deleted == false);

Если текущий каталог вашего приложения (или любого другого приложения) является тем, который вы пытаетесь удалить, это не будет ошибкой нарушения прав доступа, но каталог не будет пустым. Убедитесь, что это не ваше собственное приложение, изменив текущий каталог; также убедитесь, что каталог не открыт в какой-либо другой программе (например, Word, Excel, Total Commander и т. д.). Большинство программ перейдут в каталог последнего открытого файла, что может привести к этому.

в случае сетевых файлов Directory.DeleteHelper (recursive: = true) может вызвать IOException, что вызвано задержкой удаления файла

Я думаю, что есть файл, открытый каким-то потоком, о котором вы не знаете, у меня была та же проблема, и я решил ее, закрыв все потоки, которые указывали на каталог, который я хотел удалить.

Эта ошибка возникает, если какой-либо файл или каталог считается используемым. Это вводящая в заблуждение ошибка. Проверьте, открыты ли у вас какие-либо окна проводника или окна командной строки для какого-либо каталога в дереве или для программы, которая использует файл в этом дереве.

Я решил один возможный случай указанной проблемы, когда методы были асинхронными и закодированы следующим образом:

// delete any existing update content folder for this update
if (await fileHelper.DirectoryExistsAsync(currentUpdateFolderPath))
       await fileHelper.DeleteDirectoryAsync(currentUpdateFolderPath);

С этим:

bool exists = false;                
if (await fileHelper.DirectoryExistsAsync(currentUpdateFolderPath))
    exists = true;

// delete any existing update content folder for this update
if (exists)
    await fileHelper.DeleteDirectoryAsync(currentUpdateFolderPath);

Вывод? Существует некоторый асинхронный аспект избавления от дескриптора, используемого для проверки существования, с которым Microsoft не смогла поговорить. Это как если бы асинхронный метод внутри оператора if имел оператор if, действующий как оператор using.

Вам не нужно создавать дополнительный метод для рекурсивности или удалять файлы внутри папки extra. Все это происходит автоматически по телефону

DirectoryInfo.Delete ();

Подробности здесь .

Нечто подобное работает довольно хорошо:

  var directoryInfo = new DirectoryInfo("My directory path");
    // Delete all files from app data directory.

    foreach (var subDirectory in directoryInfo.GetDirectories())
    {
          subDirectory.Delete(true);// true set recursive paramter, when it is true delete sub file and sub folder with files too
    }

Передав true в качестве переменной для удаления метода, удаляются также вложенные файлы и вложенные папки с файлами.

Ни один из приведенных выше ответов не работал для меня. Похоже, что использование моего собственного приложения DirectoryInfoв целевом каталоге приводило к тому, что оно оставалось заблокированным.

Принудительный сборщик мусора решил проблему, но не сразу. Несколько попыток удалить при необходимости.

Обратите внимание, Directory.Existsкак оно может исчезнуть после исключения. Я не знаю, почему удаление для меня было отложено (Windows 7 SP1)

        for (int attempts = 0; attempts < 10; attempts++)
        {
            try
            {
                if (Directory.Exists(folder))
                {
                    Directory.Delete(folder, true);
                }
                return;
            }
            catch (IOException e)
            {
                GC.Collect();
                Thread.Sleep(1000);
            }
        }

        throw new Exception("Failed to remove folder.");

добавить истину во втором парам.

Directory.Delete(path, true);

Это удалит все.