Sto usando .NET 3.5, cercando di eliminare ricorsivamente una directory usando:

Directory.Delete(myPath, true);

La mia comprensione è che questo dovrebbe essere lanciato se i file sono in uso o c'è un problema di permessi, ma altrimenti dovrebbe eliminare la directory e tutto il suo contenuto.

Tuttavia, di tanto in tanto ottengo questo:

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

Non sono sorpreso che il metodo a volte passi, ma sono sorpreso di ricevere questo particolare messaggio quando ricorsivo è vero. ( So che la directory non è vuota.)

C'è un motivo per cui vedrei questo invece di AccessViolationException?

Nota del redattore: sebbene questa risposta contenga alcune informazioni utili, in realtà non è corretta sul funzionamento di Directory.Delete. Si prega di leggere i commenti per questa risposta e altre risposte a questa domanda.

Mi sono imbattuto in questo problema prima.

La radice del problema è che questa funzione non elimina i file che si trovano all'interno della struttura della directory. Quindi quello che devi fare è creare una funzione che elimini tutti i file all'interno della struttura della directory, quindi tutte le directory prima di rimuovere la directory stessa. So che questo va contro il secondo parametro ma è un approccio molto più sicuro. Inoltre, probabilmente vorrai rimuovere gli attributi di accesso SOLO LETTURA dai file subito prima di eliminarli. Altrimenti ciò solleverà un'eccezione.

Basta schiaffeggiare questo codice nel tuo progetto.

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

Inoltre, per me aggiungo personalmente una restrizione sulle aree della macchina che possono essere cancellate perché vuoi che qualcuno chiami questa funzione C:\WINDOWS (%WinDir%)o C:\.

Se si sta tentando di eliminare ricorsivamente la directory ae la directory a\bè aperta in Explorer, bverrà eliminata ma verrà visualizzato l'errore "directory non vuota" aanche se è vuota quando si va a cercare. La directory corrente di qualsiasi applicazione (incluso Explorer) mantiene un handle per la directory . Quando chiami Directory.Delete(true), cancella dal basso verso l'alto:, bquindi a. Se bè aperto in Explorer, Explorer rileverà la cancellazione di b, cambierà directory verso l'alto cd ..e ripulirà gli handle aperti. Poiché il file system funziona in modo asincrono, l' Directory.Deleteoperazione non riesce a causa di conflitti con Explorer.

Soluzione incompleta

Inizialmente ho pubblicato la seguente soluzione, con l'idea di interrompere il thread corrente per consentire a Explorer di rilasciare l'handle della directory.

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

Questo funziona solo se la directory aperta è il figlio immediato della directory che si sta eliminando. Se a\b\c\dè aperto in Explorer e lo usi su a, questa tecnica fallirà dopo l'eliminazione de c.

Una soluzione leggermente migliore

Questo metodo gestirà la cancellazione di una struttura di directory profonda anche se una delle directory di livello inferiore è aperta in Explorer.

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

Nonostante il lavoro extra di ricorrere da soli, dobbiamo ancora gestire UnauthorizedAccessExceptionciò che può accadere lungo la strada. Non è chiaro se il primo tentativo di eliminazione stia aprendo la strada per il secondo, riuscito, o se è semplicemente il ritardo temporale introdotto dal lancio / cattura di un'eccezione che consente al file system di recuperare.

Potresti essere in grado di ridurre il numero di eccezioni generate e rilevate in condizioni tipiche aggiungendo Thread.Sleep(0)a all'inizio del tryblocco. Inoltre, sussiste il rischio che, sotto un carico pesante del sistema, si possano volare entrambi i Directory.Deletetentativi e fallire. Considera questa soluzione un punto di partenza per una più robusta cancellazione ricorsiva.

Risposta generale

Questa soluzione risolve solo le peculiarità dell'interazione con Windows Explorer. Se si desidera un'operazione di eliminazione solida, una cosa da tenere a mente è che qualsiasi cosa (scanner antivirus, qualunque cosa) potrebbe avere un controllo aperto su ciò che si sta tentando di eliminare, in qualsiasi momento. Quindi devi riprovare più tardi. Quanto più tardi e quante volte si tenta, dipende da quanto sia importante che l'oggetto venga eliminato. Come indica MSDN ,

Il robusto codice di iterazione dei file deve tenere conto di molte complessità del file system.

Questa dichiarazione innocente, fornita solo con un link alla documentazione di riferimento NTFS, dovrebbe farti alzare i capelli.

( Modifica : molto. Questa risposta originariamente aveva solo la prima soluzione incompleta.)

Prima di andare oltre, controlla per i seguenti motivi che sono sotto il tuo controllo:

• La cartella è impostata come directory corrente del processo? Se sì, prima cambiarlo in qualcos'altro
• Hai aperto un file (o caricato una DLL) da quella cartella? (e ho dimenticato di chiuderlo / scaricarlo)

Altrimenti, controlla per i seguenti motivi legittimi al di fuori del tuo controllo:

• Ci sono file contrassegnati come di sola lettura in quella cartella.
• Non disponi dell'autorizzazione per l'eliminazione di alcuni di questi file.
• Il file o la sottocartella sono aperti in Esplora risorse o in un'altra app.

Se uno di questi problemi è il problema, dovresti capire perché ciò accade prima di provare a migliorare il codice di eliminazione. La tua app dovrebbe eliminare i file di sola lettura o inaccessibili? Chi li ha contrassegnati in questo modo e perché?

Una volta che hai escluso i motivi di cui sopra, c'è ancora la possibilità di fallimenti spuri. L'eliminazione avrà esito negativo se qualcuno detiene un handle per uno qualsiasi dei file o cartelle che vengono eliminati e ci sono molti motivi per cui qualcuno potrebbe enumerare la cartella o leggere i suoi file:

• cerca indicizzatori
• anti-virus
• software di backup

L'approccio generale per affrontare fallimenti spuri è quello di provare più volte, facendo una pausa tra i tentativi. Ovviamente non vuoi continuare a provare per sempre, quindi dovresti rinunciare dopo un certo numero di tentativi e lanciare un'eccezione o ignorare l'errore. Come questo:

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
}

Secondo me, un aiuto del genere dovrebbe essere usato per tutte le cancellazioni perché sono sempre possibili fallimenti spuri. Tuttavia, DEVI ADATTARE QUESTO CODICE NEL CASO DI UTILIZZO, non solo copiarlo alla cieca.

Ho avuto errori spuri per una cartella di dati interna generata dalla mia app, situata in% LocalAppData%, quindi la mia analisi è la seguente:

1. La cartella è controllata esclusivamente dalla mia applicazione e l'utente non ha alcun motivo valido per andare a contrassegnare le cose come di sola lettura o inaccessibili all'interno di quella cartella, quindi non provo a gestire quel caso.

2. Non ci sono contenuti preziosi creati dagli utenti, quindi non c'è il rischio di eliminare forzatamente qualcosa per errore.

3. Essendo una cartella di dati interna, non mi aspetto che sia aperto in Explorer, almeno non sento la necessità di gestire il caso in modo specifico (cioè sto gestendo bene quel caso tramite supporto).

4. Se tutti i tentativi falliscono, scelgo di ignorare l'errore. Nel peggiore dei casi, l'app non riesce a decomprimere alcune risorse più recenti, si arresta in modo anomalo e richiede all'utente di contattare l'assistenza, il che è accettabile per me a condizione che non accada spesso. Oppure, se l'app non si arresta in modo anomalo, lascerà indietro alcuni vecchi dati, il che è di nuovo accettabile per me.

5. Ho scelto di limitare i tentativi a 500ms (50 * 10). Questa è una soglia arbitraria che funziona nella pratica; Volevo che la soglia fosse abbastanza breve in modo che gli utenti non uccidessero l'app, pensando che avesse smesso di rispondere. D'altra parte, mezzo secondo è un sacco di tempo perché l'autore del reato finisca di elaborare la mia cartella. A giudicare da altre risposte SO che a volte trovano addirittura Sleep(0)accettabile, pochissimi utenti sperimenteranno mai più di un singolo tentativo.

6. Riprovo ogni 50 ms, che è un altro numero arbitrario. Sento che se un file viene elaborato (indicizzato, controllato) quando provo a eliminarlo, 50ms è il momento giusto per aspettarmi che l'elaborazione venga completata nel mio caso. Inoltre, 50ms è abbastanza piccolo da non provocare un notevole rallentamento; di nuovo, Sleep(0)sembra essere abbastanza in molti casi, quindi non vogliamo ritardare troppo.

7. Il codice riprova su eventuali eccezioni di I / O. Normalmente non mi aspetto eccezioni nell'accesso a% LocalAppData%, quindi ho scelto la semplicità e ho accettato il rischio di un ritardo di 500 ms nel caso in cui si verifichi un'eccezione legittima. Inoltre, non volevo trovare un modo per rilevare l'esatta eccezione su cui volevo riprovare.

Risposta asincrona moderna

La risposta accettata è semplicemente sbagliata, potrebbe funzionare per alcune persone perché il tempo impiegato per ottenere i file dal disco libera qualsiasi cosa stesse bloccando i file. Il fatto è che ciò accade perché i file vengono bloccati da altri processi / stream / azioni. Le altre risposte usano Thread.Sleep(Yuck) per riprovare a cancellare la directory dopo qualche tempo. Questa domanda deve essere rivisitata con una risposta più moderna.

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

Test unitari

Questi test mostrano un esempio di come un file bloccato può causare l' Directory.Deleteerrore e come il TryDeleteDirectorymetodo sopra risolve il problema.

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

Una cosa importante che dovrebbe essere menzionata (l'ho aggiunto come commento ma non mi è permesso) è che il comportamento del sovraccarico è cambiato da .NET 3.5 a .NET 4.0.

Directory.Delete(myPath, true);

A partire da .NET 4.0 elimina i file nella cartella stessa ma NON in 3.5. Questo può essere visto anche nella documentazione MSDN.

.NET 4.0

Elimina la directory specificata e, se indicato, eventuali sottodirectory e file nella directory.

.NET 3.5

Elimina una directory vuota e, se indicato, eventuali sottodirectory e file nella directory.

Ho avuto lo stesso problema con Delphi. E il risultato finale è stato che la mia applicazione stava bloccando la directory che volevo eliminare. In qualche modo la directory è stata bloccata mentre scrivevo (alcuni file temporanei).

Il problema era che ho fatto una semplice directory di modifica al suo genitore prima di eliminarlo.

Sono sorpreso che nessuno abbia pensato a questo semplice metodo non ricorsivo, che può eliminare directory contenenti file di sola lettura, senza la necessità di modificare l'attributo di sola lettura di ciascuno di essi.

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

(Cambia un po 'per non sparare momentaneamente una finestra cmd, che è disponibile su Internet)

È possibile riprodurre l'errore eseguendo:

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

Quando si tenta di eliminare la directory 'b', genera IOException "La directory non è vuota". È stupido da quando abbiamo appena cancellato la directory 'c'.

Da quanto ho capito, la spiegazione è che la directory 'c' è contrassegnata come cancellata. Ma la cancellazione non è ancora stata eseguita nel sistema. Il sistema ha risposto che il lavoro è stato completato, mentre in realtà è ancora in fase di elaborazione. Probabilmente il sistema attende che Esplora file si concentri sulla directory principale per eseguire il commit dell'eliminazione.

Se guardi il codice sorgente della funzione Elimina ( http://referencesource.microsoft.com/#mscorlib/system/io/directory.cs ) vedrai che utilizza la funzione nativa Win32Native.RemoveDirectory. Questo comportamento non aspettare è annotato qui:

La funzione RemoveDirectory contrassegna una directory per l'eliminazione alla chiusura. Pertanto, la directory non viene rimossa fino alla chiusura dell'ultimo handle della directory.

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

Dormire e riprovare è la soluzione. Vedi la soluzione di ryascl.

Ho avuto quegli strani problemi di autorizzazione durante l'eliminazione delle directory dei profili utente (in C: \ Documents and Settings) nonostante potessi farlo nella shell di Explorer.

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

Non ha senso per me un'operazione di "file" su una directory, ma so che funziona e questo è abbastanza per me!

Questa risposta si basa su: https://stackoverflow.com/a/1703799/184528 . La differenza con il mio codice è che quando si richiama una sottodirectory e si eliminano molti sottodirectory e file, quando necessario una chiamata a Directory non viene eseguita.

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

Non delle soluzioni precedenti ha funzionato bene per me. Ho finito usando una versione modificata della soluzione @ryascl come di seguito:

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

È possibile che tu abbia una race condition in cui un altro thread o processo sta aggiungendo file alla directory:

La sequenza sarebbe:

Deleter process A:

1. Svuota la directory
2. Elimina la directory (ora vuota).

Se qualcun altro aggiunge un file tra 1 e 2, forse 2 genererebbe l'eccezione elencata?

Ho trascorso alcune ore a risolvere questo problema e altre eccezioni con l'eliminazione della directory. Questa è la mia soluzione

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

Questo codice ha un piccolo ritardo, che non è importante per la mia applicazione. Ma fai attenzione, il ritardo potrebbe essere un problema per te se hai molte sottodirectory all'interno della directory che desideri eliminare.

L'eliminazione ricorsiva della directory che non elimina i file è certamente inaspettata. La mia soluzione per questo:

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

Ho riscontrato casi in cui ciò ha aiutato, ma in generale, Directory.Delete a eliminare i file all'interno delle directory dopo l'eliminazione ricorsiva, come documentato in msdn .

Di tanto in tanto riscontro questo comportamento irregolare anche come utente di Windows Explorer: a volte non riesco a eliminare una cartella (penso che il messaggio senza senso sia "accesso negato") ma quando eseguo il drill down e elimino gli elementi inferiori posso quindi eliminare quello superiore anche articoli. Quindi immagino che il codice sopra riportato riguardi un'anomalia del sistema operativo, non un problema di libreria di classe base.

La directory o un file al suo interno è bloccato e non può essere eliminato. Trova il colpevole che lo blocca e vedi se riesci a eliminarlo.

Sembra che avere il percorso o la sottocartella selezionati in Esplora risorse sia sufficiente per bloccare una singola esecuzione di Directory.Delete (percorso, vero), lanciando una IOException come descritto sopra e morendo invece di avviare Windows Explorer in una cartella principale e procedendo come previsto.

Ho avuto questo problema oggi. Stava succedendo perché avevo Windows Explorer aperto nella directory che cercava di essere eliminato, causando il fallimento della chiamata ricorsiva e quindi l'IOException. Assicurarsi che non vi siano maniglie aperte nella directory.

Inoltre, MSDN è chiaro che non è necessario scrivere la propria recusione: http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx

Ho avuto lo stesso problema con Windows Workflow Foundation su un server di build con TFS2012. Internamente, il flusso di lavoro chiamato Directory.Delete () con il flag ricorsivo impostato su true. Sembra essere legato alla rete nel nostro caso.

Stavamo eliminando una cartella di rilascio binaria su una condivisione di rete prima di ricrearla e ripopolarla con gli ultimi binari. Ogni altra build fallirebbe. Quando si apriva la cartella di rilascio dopo una compilazione non riuscita, la cartella era vuota, il che indica che ogni aspetto della chiamata Directory.Delete () ha avuto esito positivo tranne che per l'eliminazione della directory effettiva.

Il problema sembra essere causato dalla natura asincrona delle comunicazioni dei file di rete. Il server di compilazione ha detto al file server di eliminare tutti i file e il file server ha riferito di averlo fatto, anche se non era completamente finito. Quindi il server di compilazione ha richiesto l'eliminazione della directory e il file server ha rifiutato la richiesta perché non aveva completato completamente l'eliminazione dei file.

Due possibili soluzioni nel nostro caso:

• Costruisci la cancellazione ricorsiva nel nostro codice con ritardi e verifiche tra ogni passaggio
• Riprova fino a X volte dopo una IOException, dando un ritardo prima di riprovare

Quest'ultimo metodo è veloce e sporco ma sembra fare il trucco.

Ciò è dovuto a FileChangesNotifications.

Succede da ASP.NET 2.0. Quando elimini una cartella all'interno di un'app, questa viene riavviata . Puoi vederlo tu stesso, usando ASP.NET Health Monitoring .

Aggiungi questo codice al tuo web.config / configuration / system.web:

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

Dopo quel check out Windows Log -> Application. Cosa sta succedendo:

Quando si elimina una cartella, se è presente una sottocartella, Delete(path, true)elimina prima la sottocartella. È sufficiente che FileChangesMonitor sia a conoscenza della rimozione e della chiusura dell'app. Nel frattempo la tua directory principale non è stata ancora cancellata. Questo è l'evento dal registro:

Delete() non ha terminato il suo lavoro e poiché l'app si sta chiudendo, genera un'eccezione:

Quando non hai sottocartelle in una cartella che stai eliminando, Elimina () elimina solo tutti i file e quella cartella, anche l'app viene riavviata, ma non ottieni eccezioni , poiché il riavvio dell'app non interrompe nulla. Tuttavia, perdi tutte le sessioni in-process, l'app non risponde alle richieste al riavvio, ecc.

E adesso?

Esistono alcune soluzioni alternative e modifiche per disabilitare questo comportamento, Directory Junction , Disattivazione di FCN con il Registro di sistema , Arresto di FileChangesMonitor utilizzando Reflection (poiché non esiste un metodo esposto) , ma tutti non sembrano essere corretti, perché FCN è disponibile per un Motivo. Si occupa della struttura della tua app , che non è la struttura dei tuoi dati . La risposta breve è: posizionare le cartelle che si desidera eliminare al di fuori della propria app. FileChangesMonitor non riceverà notifiche e l'app non verrà riavviata ogni volta. Non otterrai eccezioni. Per renderli visibili dal web ci sono due modi:

1. Crea un controller che gestisca le chiamate in arrivo e poi rispedisca i file leggendo dalla cartella all'esterno di un'app (all'esterno di wwwroot).

2. Se il tuo progetto è grande e le prestazioni sono le più importanti, imposta un server web separato piccolo e veloce per servire contenuti statici. In questo modo lascerai a IIS il suo lavoro specifico. Potrebbe essere sulla stessa macchina (mangusta per Windows) o su un'altra macchina (nginx per Linux). La buona notizia è che non è necessario pagare una licenza Microsoft aggiuntiva per configurare un server di contenuti statici su Linux.

Spero che sia di aiuto.

Come accennato in precedenza, la soluzione "accettata" non riesce sui punti di analisi - eppure la gente lo contrassegna ancora (???). C'è una soluzione molto più breve che replica correttamente la funzionalità:

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

Lo so, non gestisce i casi di autorizzazione menzionati più avanti, ma a tutti gli effetti FAR BETTER fornisce le funzionalità previste da Directory.Delete () originale / stock - e con molto meno codice .

Puoi continuare a lavorare in modo sicuro perché la vecchia directory sarà fuori mano ... anche se non sparita perché il "file system sta ancora recuperando" (o qualunque scusa abbia dato MS per fornire una funzione non funzionante) .

Come vantaggio, se sai che la tua directory di destinazione è grande / profonda e non vuoi aspettare (o preoccuparti delle eccezioni), l'ultima riga può essere sostituita con:

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

Sei ancora sicuro di continuare a lavorare.

Questo problema può apparire su Windows quando ci sono file in una directory (o in qualsiasi sottodirectory) la cui lunghezza del percorso è maggiore di 260 simboli.

In tali casi è necessario eliminare \\\\?\C:\mydiranziché C:\mydir. Informazioni sul limite di 260 simboli che puoi leggere qui .

Ho risolto con questa tecnica millenaria (puoi lasciare il Thread. Dormi da solo nella presa)

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

Se la directory corrente dell'applicazione (o di qualsiasi altra applicazione) è quella che stai tentando di eliminare, non si verificherà un errore di violazione dell'accesso ma una directory non è vuota. Assicurati che non sia la tua applicazione cambiando la directory corrente; inoltre, assicurati che la directory non sia aperta in qualche altro programma (es. Word, Excel, Total Commander, ecc.). La maggior parte dei programmi eseguirà il cd nella directory dell'ultimo file aperto, il che causerebbe ciò.

nel caso di file di rete, Directory.DeleteHelper (ricorsivo: = true) potrebbe causare IOException causata dal ritardo nell'eliminazione del file

Penso che ci sia un file aperto da qualche stream di cui non sei a conoscenza ho avuto lo stesso problema e l'ho risolto chiudendo tutti i flussi che puntavano alla directory che volevo eliminare.

Questo errore si verifica se qualsiasi file o directory viene considerato in uso. È un errore fuorviante. Verificare se sono presenti finestre di Esplora risorse o finestre della riga di comando aperte su una directory della struttura o su un programma che utilizza un file nella struttura.

Ho risolto una possibile istanza del problema dichiarato quando i metodi erano asincroni e codificati in questo modo:

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

Con questo:

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

Conclusione? Esistono alcuni aspetti asincroni dell'eliminazione dell'handle utilizzato per verificare l'esistenza con cui Microsoft non è stata in grado di parlare. È come se il metodo asincrono all'interno di un'istruzione if abbia l'istruzione if che agisce come un'istruzione using.

Non è necessario creare un metodo aggiuntivo per la ricorsività o eliminare i file all'interno della cartella extra. Tutto questo facendo automaticamente chiamando

DirectoryInfo.Delete ();

I dettagli sono qui .

Qualcosa del genere funziona abbastanza bene:

  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
    }

passando true come variabile per eliminare il metodo, eliminerà anche i file secondari e la cartella secondaria con i file.

Nessuna delle risposte sopra ha funzionato per me. Sembra che l'utilizzo della mia app nella DirectoryInfodirectory di destinazione lo abbia bloccato.

La forzatura della garbage collection sembrava risolvere il problema, ma non subito. Alcuni tentativi di eliminazione dove richiesto.

Nota Directory.Existscome può scomparire dopo un'eccezione. Non so perché l'eliminazione per me è stata ritardata (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.");

aggiungi true nel secondo parametro.

Directory.Delete(path, true);

Rimuoverà tutto.