Korzystam z .NET 3.5, próbując rekurencyjnie usunąć katalog używając:

Directory.Delete(myPath, true);

Rozumiem, że powinno to wyrzucić, jeśli pliki są w użyciu lub występuje problem z uprawnieniami, ale w przeciwnym razie powinien usunąć katalog i całą jego zawartość.

Jednak czasami otrzymuję to:

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)
    ...

Nie dziwię się, że metoda czasami rzuca, ale jestem zaskoczony otrzymaniem tego konkretnego komunikatu, gdy rekurencja jest prawdziwa. ( Wiem, że katalog nie jest pusty.)

Czy istnieje powód, dla którego widziałbym to zamiast AccessViolationException?

Uwaga edytora: Mimo że ta odpowiedź zawiera przydatne informacje, jest nieprawidłowa pod względem działania Directory.Delete. Przeczytaj komentarze do tej odpowiedzi i inne odpowiedzi na to pytanie.

Wcześniej napotkałem ten problem.

Przyczyną problemu jest to, że ta funkcja nie usuwa plików znajdujących się w strukturze katalogów. Musisz więc stworzyć funkcję, która usuwa wszystkie pliki w strukturze katalogów, a następnie wszystkie katalogi przed usunięciem samego katalogu. Wiem, że jest to sprzeczne z drugim parametrem, ale jest to znacznie bezpieczniejsze podejście. Ponadto prawdopodobnie będziesz chciał usunąć atrybuty dostępu TYLKO DO CZYTANIA z plików bezpośrednio przed ich usunięciem. W przeciwnym razie powstanie wyjątek.

Po prostu włóż ten kod do swojego projektu.

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);
}

Również dla mnie osobiście dodaję ograniczenie w obszarach komputera, które można usunąć, ponieważ chcesz, aby ktoś wywoływał tę funkcję na C:\WINDOWS (%WinDir%)lub C:\.

Jeśli próbujesz rekurencyjnie usunąć katalog, aa katalog a\bjest otwarty w Eksploratorze, bzostanie usunięty, ale pojawi się błąd „katalog nie jest pusty”, amimo że jest pusty, gdy idziesz szukać. Bieżący katalog dowolnej aplikacji (w tym Eksploratora) zachowuje uchwyt do katalogu . Gdy zadzwonisz Directory.Delete(true), usuwa się od dołu do góry:, ba następnie a. Jeśli bjest otwarty w Eksploratorze, Eksplorator wykryje usunięcie b, zmieni katalog do góry cd ..i wyczyści otwarte uchwyty. Ponieważ system plików działa asynchronicznie, plikDirectory.Delete operacja kończy się niepowodzeniem z powodu konfliktu z Eksploratorem.

Niekompletne rozwiązanie

Pierwotnie opublikowałem następujące rozwiązanie, z myślą o przerwaniu bieżącego wątku, aby dać czas Eksploratorowi na zwolnienie uchwytu katalogu.

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

Ale działa to tylko wtedy, gdy otwarty katalog jest bezpośrednim dzieckiem potomka usuwanego katalogu. Jeśli a\b\c\djest otwarty w Eksploratorze i używasz go a, ta technika zawiedzie po usunięciu di c.

Nieco lepsze rozwiązanie

Ta metoda obsłuży usuwanie głębokiej struktury katalogów, nawet jeśli jeden z katalogów niższego poziomu jest otwarty w Eksploratorze.

/// <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);
    }
}

Pomimo dodatkowej pracy polegającej na samodzielnym wykonywaniu rekurencji nadal musimy sobie z tym poradzićUnauthorizedAccessException które mogą wystąpić po drodze. Nie jest jasne, czy pierwsza próba usunięcia toruje drogę drugiej, udanej, czy tylko opóźnienie czasowe wprowadzone przez zgłoszenie wyjątku, który pozwala systemowi plików na nadrobienie zaległości.

Możesz być w stanie zmniejszyć liczbę wyjątków zgłaszanych i wychwytywanych w typowych warunkach, dodając a Thread.Sleep(0)na początku trybloku. Ponadto istnieje ryzyko, że pod dużym obciążeniem systemu możesz przelecieć przez obie Directory.Deletepróby i zawieść. Rozważ to rozwiązanie jako punkt wyjścia do bardziej niezawodnego usuwania rekurencyjnego.

Ogólna odpowiedź

To rozwiązanie dotyczy tylko osobliwości interakcji z Eksploratorem Windows. Jeśli chcesz mieć solidną operację usuwania, pamiętaj, że wszystko (skaner antywirusowy, cokolwiek) może mieć otwarty uchwyt do tego, co próbujesz usunąć w dowolnym momencie. Więc musisz spróbować ponownie później. To, ile później i ile razy spróbujesz, zależy od tego, jak ważne jest usunięcie obiektu. Jak wskazuje MSDN ,

Solidny kod iteracji plików musi uwzględniać wiele złożoności systemu plików.

To niewinne oświadczenie, zawierające jedynie link do dokumentacji referencyjnej NTFS, powinno sprawić, że twoje włosy staną na nogi.

( Edycja : Dużo. Ta odpowiedź pierwotnie miała tylko pierwsze, niepełne rozwiązanie).

Zanim przejdziesz dalej, sprawdź następujące przyczyny, które są pod twoją kontrolą:

• Czy folder jest ustawiony jako bieżący katalog Twojego procesu? Jeśli tak, zmień to najpierw na coś innego.
• Czy otworzyłeś plik (lub załadowałeś bibliotekę DLL) z tego folderu? (i zapomniałem go zamknąć / rozładować)

W przeciwnym razie sprawdź następujące uzasadnione powody, na które nie masz wpływu:

• W tym folderze znajdują się pliki oznaczone jako tylko do odczytu.
• Nie masz uprawnień do usuwania niektórych z tych plików.
• Plik lub podfolder jest otwarty w Eksploratorze lub innej aplikacji.

Jeśli którykolwiek z powyższych problemów stanowi problem, powinieneś zrozumieć, dlaczego tak się dzieje, zanim spróbujesz poprawić kod usuwania. Czy Twoja aplikacja powinna usuwać pliki tylko do odczytu lub niedostępne? Kto tak je oznaczył i dlaczego?

Po wykluczeniu powyższych przyczyn nadal istnieje możliwość fałszywych awarii. Usunięcie nie powiedzie się, jeśli ktoś będzie trzymał uchwyt usuwanego pliku lub folderu, a istnieje wiele powodów, dla których ktoś może wyliczyć folder lub odczytać jego pliki:

• indeksuj wyszukiwanie
• antywirusy
• oprogramowanie do tworzenia kopii zapasowych

Ogólne podejście do radzenia sobie z fałszywymi niepowodzeniami polega na wielokrotnym próbowaniu, przerywaniu między próbami. Oczywiście nie chcesz próbować wiecznie, więc powinieneś poddać się po pewnej liczbie prób i albo rzucić wyjątek, albo zignorować błąd. Lubię to:

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
}

Moim zdaniem takiego pomocnika należy używać do wszystkich operacji usuwania, ponieważ fałszywe niepowodzenia są zawsze możliwe. NALEŻY DOSTOSOWAĆ TEN KOD DO SWOJEJ PRZYPADKU, a nie tylko na ślepo kopiować.

Miałem fałszywe awarie wewnętrznego folderu danych generowanego przez moją aplikację, zlokalizowanego pod% LocalAppData%, więc moja analiza wygląda następująco:

1. Folder jest kontrolowany wyłącznie przez moją aplikację, a użytkownik nie ma uzasadnionego powodu, aby oznaczać rzeczy jako tylko do odczytu lub niedostępne w tym folderze, więc nie próbuję obsługiwać tej sprawy.

2. Nie ma tam żadnych cennych rzeczy stworzonych przez użytkowników, więc nie ma ryzyka wymuszonego usunięcia czegoś przez pomyłkę.

3. Będąc wewnętrznym folderem danych, nie oczekuję, że będzie on otwarty w Eksploratorze, a przynajmniej nie czuję potrzeby szczegółowej obsługi sprawy (tj. Dobrze sobie radzę z tą sprawą poprzez wsparcie).

4. Jeśli wszystkie próby zakończą się niepowodzeniem, zdecyduję się zignorować błąd. W najgorszym przypadku aplikacja nie rozpakowuje niektórych nowszych zasobów, ulega awarii i monituje użytkownika o kontakt z pomocą techniczną, co jest dla mnie dopuszczalne, o ile nie zdarza się to często. Lub, jeśli aplikacja się nie zawiesi, pozostawi po sobie trochę starych danych, co znowu jest dla mnie akceptowalne.

5. Wybieram ograniczenie ponownych prób do 500ms (50 * 10). Jest to arbitralny próg, który działa w praktyce; Chciałem, aby próg był wystarczająco krótki, aby użytkownicy nie zabili aplikacji, sądząc, że przestała ona odpowiadać. Z drugiej strony, pół sekundy to dużo czasu dla sprawcy na zakończenie przetwarzania mojego folderu. Sądząc po innych odpowiedziach SO, które czasami wydają się nawet Sleep(0)do zaakceptowania, bardzo niewielu użytkowników kiedykolwiek doświadczy więcej niż jednej próby.

6. Próbuję co 50 ms, co jest kolejną dowolną liczbą. Wydaje mi się, że jeśli plik jest przetwarzany (indeksowany, sprawdzany), gdy próbuję go usunąć, 50 ms to właściwy czas, aby oczekiwać zakończenia przetwarzania w moim przypadku. Ponadto 50 ms jest wystarczająco małe, aby nie spowodować zauważalnego spowolnienia; znowu Sleep(0)wydaje się wystarczające w wielu przypadkach, więc nie chcemy zbytnio opóźniać.

7. Kod próbuje powtórzyć wyjątki we / wy. Zwykle nie oczekuję żadnych wyjątków w dostępie do% LocalAppData%, więc wybrałem prostotę i zaakceptowałem ryzyko 500 ms opóźnienia w przypadku wystąpienia uzasadnionego wyjątku. Nie chciałem też znaleźć sposobu na wykrycie dokładnego wyjątku, na którym chcę spróbować ponownie.

Nowoczesna odpowiedź asynchroniczna

Przyjęta odpowiedź jest po prostu błędna, może działać dla niektórych osób, ponieważ czas potrzebny na pobranie plików z dysku uwalnia wszystko, co je blokowało. Faktem jest, że dzieje się tak, ponieważ pliki są blokowane przez inny proces / strumień / akcję. Inne odpowiedzi używają Thread.Sleep(Fuj), aby ponownie spróbować usunąć katalog po pewnym czasie. To pytanie wymaga ponownej odpowiedzi z bardziej nowoczesną odpowiedzią.

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;
}

Testy jednostkowe

Testy te pokazują przykład, w jaki sposób zablokowany plik może spowodować Directory.Deleteawarię i jak TryDeleteDirectorypowyższa metoda rozwiązuje problem.

[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);
        }
    }
}

Jedną ważną rzeczą, o której należy wspomnieć (dodałem to jako komentarz, ale nie wolno mi), że zachowanie przeciążenia zmieniło się z .NET 3.5 na .NET 4.0.

Directory.Delete(myPath, true);

Począwszy od .NET 4.0 usuwa pliki w samym folderze, ale NIE w 3.5. Można to również zobaczyć w dokumentacji MSDN.

.NET 4.0

Usuwa określony katalog oraz, jeśli jest to wskazane, wszystkie podkatalogi i pliki w katalogu.

.NET 3.5

Usuwa pusty katalog i, jeśli jest to wskazane, wszystkie podkatalogi i pliki w katalogu.

Miałem ten sam problem za Delphi. W rezultacie moja aplikacja blokowała katalog, który chciałem usunąć. Jakoś katalog został zablokowany, kiedy do niego pisałem (niektóre pliki tymczasowe).

Złap 22 polegał na tym, że przed usunięciem zrobiłem prosty katalog zmian do jego rodzica.

Dziwi mnie, że nikt nie pomyślał o tej prostej nierekurencyjnej metodzie, która może usuwać katalogi zawierające pliki tylko do odczytu, bez potrzeby zmiany atrybutu tylko do odczytu każdego z nich.

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

(Zmień trochę, aby nie uruchamiać na chwilę okna cmd, które jest dostępne w całym Internecie)

Możesz odtworzyć błąd, uruchamiając:

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");

Podczas próby usunięcia katalogu „b” zgłasza wyjątek IOException „Katalog nie jest pusty”. To głupie, ponieważ właśnie usunęliśmy katalog „c”.

Z mojego zrozumienia wynika, że ​​katalog „c” jest stemplowany jako usunięty. Ale usunięcie nie jest jeszcze zatwierdzone w systemie. System ma odpowiedź, że zadanie zostało wykonane, podczas gdy w rzeczywistości jest nadal przetwarzane. System prawdopodobnie czeka, aż eksplorator plików skupi się na katalogu nadrzędnym, aby zatwierdzić usunięcie.

Jeśli spojrzysz na kod źródłowy funkcji Delete ( http://referencesource.microsoft.com/#mscorlib/system/io/directory.cs ), zobaczysz, że używa natywnej funkcji Win32Native.RemoveDirectory. Zwrócono uwagę na to, że nie trzeba czekać:

Funkcja RemoveDirectory oznacza katalog do usunięcia po zamknięciu. Dlatego katalog nie jest usuwany, dopóki ostatni uchwyt do katalogu nie zostanie zamknięty.

( http://msdn.microsoft.com/en-us/library/windows/desktop/aa365488(v=vs.85).aspx )

Uśpij i spróbuj ponownie. Por. Rozwiązanie ryascl.

Miałem te dziwne problemy z uprawnieniami podczas usuwania katalogów profilu użytkownika (w C: \ Documents and Settings), mimo że mogłem to zrobić w powłoce Eksploratora.

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

Nie ma dla mnie sensu, co robi operacja „pliku” na katalogu, ale wiem, że to działa i to mi wystarczy!

Ta odpowiedź jest oparta na: https://stackoverflow.com/a/1703799/184528 . Różnica w stosunku do mojego kodu polega na tym, że rekursywne usuwanie wielu podkatalogów i plików następuje tylko wtedy, gdy jest to konieczne.

    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);
        } 
    }

Żadne z powyższych rozwiązań nie działało dla mnie dobrze. Skończyło się na użyciu edytowanej wersji rozwiązania @ryascl, jak poniżej:

    /// <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);
        }
    }

Czy to możliwe, że masz wyścig, w którym inny wątek lub proces dodaje pliki do katalogu:

Sekwencja będzie wyglądać następująco:

Proces Deleter A:

1. Opróżnij katalog
2. Usuń (teraz pusty) katalog.

Jeśli ktoś inny doda plik między 1 a 2, to może 2 rzuciłby wymieniony wyjątek?

Spędziłem kilka godzin, aby rozwiązać ten problem i inne wyjątki związane z usunięciem katalogu. To jest moje rozwiązanie

 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);
        }
    }

Ten kod ma małe opóźnienie, co nie jest ważne dla mojej aplikacji. Ale bądź ostrożny, opóźnienie może być dla ciebie problemem, jeśli masz wiele podkatalogów w katalogu, który chcesz usunąć.

Rekurencyjne usuwanie katalogu, który nie usuwa plików, jest z pewnością nieoczekiwane. Moja poprawka do tego:

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

Wystąpiły przypadki, w których to pomogło, ale ogólnie Directory.Delete usuwa pliki wewnątrz katalogów po rekurencyjnym usuwaniu Wystąpiły udokumentowano w msdn .

Od czasu do czasu spotykam się z tym nieregularnym zachowaniem również jako użytkownik Eksploratora Windows: Czasami nie mogę usunąć folderu (wydaje się, że nonsensowny komunikat to „odmowa dostępu”), ale kiedy przechodzę do szczegółów i usuwam dolne elementy, mogę następnie usunąć górną przedmioty również. Sądzę więc, że powyższy kod dotyczy anomalii systemu operacyjnego - nie problemu biblioteki podstawowej.

Katalog lub plik w nim jest zablokowany i nie można go usunąć. Znajdź winowajcę, który go blokuje, i sprawdź, czy możesz go wyeliminować.

Wygląda na to, że wybranie ścieżki lub podfolderu w Eksploratorze Windows wystarczy, aby zablokować pojedyncze wykonanie Directory.Delete (ścieżka, prawda), zgłaszając wyjątek IOException, jak opisano powyżej, i umiera zamiast uruchamiać Eksploratora Windows do folderu nadrzędnego i postępować jak spodziewany.

Miałem dzisiaj ten problem. Działo się tak, ponieważ miałem eksploratora Windows otwartego na katalog, który próbował zostać usunięty, powodując niepowodzenie wywołania rekurencyjnego, a tym samym wyjątek IOException. Upewnij się, że nie ma otwartych uchwytów do katalogu.

Ponadto MSDN jest jasne, że nie musisz pisać własnych wniosków: http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx

Miałem ten sam problem z Windows Workflow Foundation na serwerze kompilacji z TFS2012. Wewnętrznie przepływ pracy o nazwie Directory.Delete () z flagą rekurencyjną ustawioną na true. W naszym przypadku wydaje się, że jest związany z siecią.

Usuwaliśmy binarny folder upuszczania z udziału sieciowego przed ponownym utworzeniem i ponownym zapełnieniem go najnowszymi plikami binarnymi. Każda inna kompilacja zawiedzie. Podczas otwierania folderu upuszczania po nieudanej kompilacji folder był pusty, co wskazuje, że każdy aspekt wywołania Directory.Delete () był udany, z wyjątkiem usunięcia faktycznie katalogu.

Problem wydaje się być spowodowany asynchroniczną naturą komunikacji plików sieciowych. Serwer kompilacji powiedział serwerowi plików, aby usunął wszystkie pliki, a serwer plików zgłosił, że tak, mimo że nie został całkowicie ukończony. Następnie serwer kompilacji zażądał usunięcia katalogu, a serwer plików odrzucił żądanie, ponieważ nie zakończył całkowicie usuwania plików.

Dwa możliwe rozwiązania w naszym przypadku:

• Zbuduj rekurencyjne usuwanie w naszym własnym kodzie z opóźnieniami i weryfikacjami między każdym krokiem
• Spróbuj ponownie do X razy po IOException, dając opóźnienie przed ponowną próbą

Ta ostatnia metoda jest szybka i brudna, ale wydaje się, że załatwia sprawę.

Wynika to z FileChangesNotifications.

Dzieje się tak od czasu ASP.NET 2.0. Usunięty folder w aplikacji zostanie ponownie uruchomiony . Możesz to zobaczyć sam, korzystając z monitorowania kondycji ASP.NET .

Po prostu dodaj ten kod do swojego web.config / configuration / system.web:

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

Następnie sprawdź Windows Log -> Application. Co się dzieje:

Po usunięciu folderu, jeśli istnieje jakiś podfolder, Delete(path, true)najpierw usuwa podfolder. Wystarczy, aby FileChangesMonitor wiedział o usuwaniu i wyłączaniu aplikacji. Tymczasem twój katalog główny nie został jeszcze usunięty. To jest wydarzenie z Log:

Delete() nie zakończył pracy, a ponieważ aplikacja się wyłącza, pojawia się wyjątek:

Jeśli nie masz żadnych podfolderów w usuwanym folderze, Delete () po prostu usuwa wszystkie pliki i ten folder, aplikacja również jest restartowana, ale nie otrzymujesz żadnych wyjątków , ponieważ ponowne uruchomienie aplikacji niczego nie przerywa. Ale nadal tracisz wszystkie sesje w toku, aplikacja nie odpowiada na żądania przy ponownym uruchomieniu itp.

Co teraz?

Istnieją pewne obejścia i poprawki, aby wyłączyć to zachowanie, łączenie katalogów , wyłączanie FCN za pomocą rejestru , zatrzymywanie FileChangesMonitor za pomocą Reflection (ponieważ nie ma metody narażonej) , ale nie wszystkie wydają się mieć rację, ponieważ FCN jest dostępny dla powód. Dba o strukturę Twojej aplikacji , która nie jest strukturą Twoich danych . Krótka odpowiedź brzmi: umieść foldery, które chcesz usunąć, poza aplikacją. FileChangesMonitor nie otrzyma żadnych powiadomień, a aplikacja nie będzie ponownie uruchamiana za każdym razem. Nie dostaniesz żadnych wyjątków. Aby były widoczne z Internetu, istnieją dwa sposoby:

1. Utwórz kontroler, który obsługuje połączenia przychodzące, a następnie odsyła pliki, odczytując z folderu poza aplikacją (poza wwwroot).

2. Jeśli Twój projekt jest duży, a wydajność jest najważniejsza, skonfiguruj osobny mały i szybki serwer WWW do obsługi zawartości statycznej. W ten sposób IIS pozostawi swoją konkretną pracę. Może to być ten sam komputer (mongoose dla Windows) lub inny komputer (nginx dla Linux). Dobra wiadomość jest taka, że ​​nie musisz płacić dodatkowej licencji Microsoft, aby skonfigurować statyczny serwer treści na Linuksie.

Mam nadzieję że to pomoże.

Jak wspomniano powyżej, „zaakceptowane” rozwiązanie zawodzi przy ponownej analizie punktów - ale ludzie nadal go oceniają (???). Istnieje o wiele krótsze rozwiązanie, które poprawnie powiela funkcjonalność:

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);
}

Wiem, że nie obsługuje przypadków uprawnień wymienionych później, ale dla wszystkich zamiarów i celów FAR LEPIEJ zapewnia oczekiwaną funkcjonalność oryginalnego katalogu / stock.Delete () - oraz z dużo mniejszym kodem .

Możesz bezpiecznie kontynuować przetwarzanie, ponieważ stary katalog nie będzie przeszkadzał ... nawet jeśli nie zniknie, ponieważ „system plików wciąż nadrabia zaległości” (lub jakąkolwiek wymówkę, jaką MS podało, by zapewnić zepsutą funkcję) .

Jako korzyść, jeśli wiesz, że twój katalog docelowy jest duży / głęboki i nie chcesz czekać (lub zawracać sobie głowy wyjątkami), ostatni wiersz można zastąpić:

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

Nadal możesz bezpiecznie kontynuować pracę.

Ten problem może pojawić się w systemie Windows, gdy w katalogu (lub w dowolnym podkatalogu) znajdują się pliki, których długość ścieżki jest większa niż 260 symboli.

W takich przypadkach musisz usunąć \\\\?\C:\mydirzamiast C:\mydir. O limicie 260 symboli możesz przeczytać tutaj .

Rozwiązałem tę tysiącletnią technikę (możesz opuścić Nić, sam spać w haczyku)

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);

Jeśli bieżący katalog aplikacji (lub innej aplikacji) to ten, który próbujesz usunąć, nie będzie to błąd naruszenia zasad dostępu, ale katalog nie będzie pusty. Upewnij się, że nie jest to twoja aplikacja, zmieniając bieżący katalog; Upewnij się również, że katalog nie jest otwarty w jakimś innym programie (np. Word, Excel, Total Commander itp.). Większość programów przejdzie do katalogu ostatnio otwartego pliku, co spowodowałoby to.

w przypadku plików sieciowych Directory.DeleteHelper (rekursywny: = prawda) może powodować wyjątek IOException, który jest spowodowany opóźnieniem usunięcia pliku

Myślę, że istnieje jakiś plik otwarty przez jakiś strumień, o którym nie wiesz, że miałem ten sam problem i rozwiązałem go, zamykając wszystkie strumienie wskazujące katalog, który chciałem usunąć.

Ten błąd występuje, jeśli jakikolwiek plik lub katalog zostanie uznany za używany. Jest to błąd wprowadzający w błąd. Sprawdź, czy masz jakieś okna eksploratora lub okna wiersza poleceń otwarte dla dowolnego katalogu w drzewie lub programu, który używa pliku w tym drzewie.

Rozwiązałem jeden możliwy przypadek podanego problemu, gdy metody były asynchronizowane i kodowane w następujący sposób:

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

Z tym:

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);

Wniosek? Istnieje pewien asynchroniczny aspekt pozbycia się uchwytu używanego do sprawdzania istnienia, z którym Microsoft nie był w stanie rozmawiać. To tak, jakby metoda asynchroniczna w instrukcji if miała instrukcję if działającą jak instrukcja using.

Nie musisz tworzyć dodatkowych metod rekurencyjności ani usuwać plików w folderze dodatkowym. Wszystko to odbywa się automatycznie przez telefon

DirectoryInfo.Delete ();

Szczegóły są tutaj .

Coś takiego działa całkiem dobrze:

  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
    }

przekazanie wartości true jako zmiennej w celu usunięcia metody spowoduje usunięcie również plików podrzędnych i podfolderów z plikami.

Żadna z powyższych odpowiedzi nie działała dla mnie. Wygląda na to, że użycie mojej aplikacji DirectoryInfodo katalogu docelowego spowodowało, że pozostała zablokowana.

Wymuszanie wyrzucania elementów bezużytecznych rozwiązało problem, ale nie od razu. Kilka prób usunięcia w razie potrzeby.

Zwróć uwagę na Directory.Existsto, że może zniknąć po wyjątku. Nie wiem, dlaczego usunięcie było dla mnie opóźnione (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.");

dodaj true w drugim param.

Directory.Delete(path, true);

Usunie wszystko.