J'utilise .NET 3.5, essayant de supprimer récursivement un répertoire en utilisant:

Directory.Delete(myPath, true);

Ma compréhension est que cela devrait jeter si des fichiers sont en cours d'utilisation ou s'il y a un problème d'autorisations, mais sinon cela devrait supprimer le répertoire et tout son contenu.

Cependant, j'obtiens parfois ceci:

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

Je ne suis pas surpris que la méthode lance parfois, mais je suis surpris de recevoir ce message particulier lorsque récursif est vrai. (Je sais que le répertoire n'est pas vide.)

Y a-t-il une raison pour laquelle je verrais ceci au lieu de AccessViolationException?

Note de l'éditeur: Bien que cette réponse contienne des informations utiles, elle est incorrecte sur le fonctionnement de Directory.Delete. Veuillez lire les commentaires de cette réponse et les autres réponses à cette question.

J'ai rencontré ce problème auparavant.

La racine du problème est que cette fonction ne supprime pas les fichiers qui se trouvent dans la structure du répertoire. Donc, ce que vous devrez faire est de créer une fonction qui supprime tous les fichiers de la structure de répertoires puis tous les répertoires avant de supprimer le répertoire lui-même. Je sais que cela va à l'encontre du deuxième paramètre, mais c'est une approche beaucoup plus sûre. En outre, vous souhaiterez probablement supprimer les attributs d'accès en lecture seule des fichiers juste avant de les supprimer. Sinon, cela déclenchera une exception.

Insérez simplement ce code dans votre projet.

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

De plus, pour moi, j'ajoute personnellement une restriction sur les zones de la machine qui peuvent être supprimées car voulez-vous que quelqu'un appelle cette fonction sur C:\WINDOWS (%WinDir%)ou C:\.

Si vous essayez de supprimer récursivement le répertoire aet que le répertoire a\best ouvert dans l'Explorateur, bil sera supprimé mais vous obtiendrez l'erreur «le répertoire n'est pas vide» car amême s'il est vide lorsque vous allez regarder. Le répertoire actuel de n'importe quelle application (y compris Explorer) conserve un descripteur sur le répertoire . Lorsque vous appelez Directory.Delete(true), il supprime de bas en haut:, bpuis a. Si best ouvert dans Explorer, Explorer détectera la suppression de b, changera de répertoire vers le haut cd ..et nettoiera les poignées ouvertes. Étant donné que le système de fichiers fonctionne de manière asynchrone, l' Directory.Deleteopération échoue en raison de conflits avec Explorer.

Solution incomplète

J'ai initialement publié la solution suivante, avec l'idée d'interrompre le thread actuel pour permettre à l'Explorateur de libérer le descripteur de répertoire.

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

Mais cela ne fonctionne que si le répertoire ouvert est l' enfant immédiat du répertoire que vous supprimez. Si a\b\c\dest ouvert dans l'Explorateur et que vous l'utilisez sur a, cette technique échouera après la suppression de det c.

Une solution un peu meilleure

Cette méthode gérera la suppression d'une structure de répertoires approfondie même si l'un des répertoires de niveau inférieur est ouvert dans l'Explorateur.

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

Malgré le travail supplémentaire de récursivité par nous-mêmes, nous devons encore gérer ce UnauthorizedAccessExceptionqui peut survenir en cours de route. Il n'est pas clair si la première tentative de suppression ouvre la voie à la deuxième, réussie, ou si c'est simplement le délai de temporisation introduit par le lancement / la capture d'une exception qui permet au système de fichiers de rattraper son retard.

Vous pourriez être en mesure de réduire le nombre d'exceptions levées et interceptées dans des conditions typiques en ajoutant un Thread.Sleep(0)au début du trybloc. De plus, il existe un risque que sous une charge système élevée, vous puissiez survoler les deux Directory.Deletetentatives et échouer. Considérez cette solution comme un point de départ pour une suppression récursive plus robuste.

Réponse générale

Cette solution ne traite que les particularités d'interagir avec l'Explorateur Windows. Si vous voulez une opération de suppression à toute épreuve, une chose à garder à l'esprit est que tout (antivirus, peu importe) pourrait avoir une idée ouverte de ce que vous essayez de supprimer, à tout moment. Vous devez donc réessayer plus tard. Le nombre de tentatives ultérieures et le nombre de tentatives dépendent de l'importance de la suppression de l'objet. Comme l' indique MSDN ,

Un code d'itération de fichier robuste doit prendre en compte de nombreuses complexités du système de fichiers.

Cette déclaration innocente, fournie uniquement avec un lien vers la documentation de référence NTFS, devrait faire lever vos cheveux.

( Edit : Beaucoup. Cette réponse n'avait à l'origine que la première solution incomplète.)

Avant d'aller plus loin, vérifiez les raisons suivantes qui sont sous votre contrôle:

• Le dossier est-il défini comme répertoire actuel de votre processus? Si oui, changez-le d'abord en autre chose.
• Avez-vous ouvert un fichier (ou chargé une DLL) à partir de ce dossier? (et j'ai oublié de le fermer / décharger)

Sinon, vérifiez les raisons légitimes suivantes hors de votre contrôle:

• Il y a des fichiers marqués en lecture seule dans ce dossier.
• Vous ne disposez pas d'une autorisation de suppression pour certains de ces fichiers.
• Le fichier ou le sous-dossier est ouvert dans l'Explorateur ou une autre application.

Si l'un des problèmes ci-dessus pose problème, vous devez comprendre pourquoi cela se produit avant d'essayer d'améliorer votre code de suppression. Au cas où votre application est la suppression des fichiers en lecture seule ou inaccessibles? Qui les a marqués de cette façon et pourquoi?

Une fois que vous avez exclu les raisons ci-dessus, il y a toujours une possibilité de fausses pannes. La suppression échouera si quelqu'un détient une poignée sur l'un des fichiers ou dossiers en cours de suppression, et il existe de nombreuses raisons pour lesquelles quelqu'un peut énumérer le dossier ou lire ses fichiers:

• indexeurs de recherche
• anti-virus
• logiciel de sauvegarde

L'approche générale pour gérer les pannes parasites consiste à essayer plusieurs fois, en faisant une pause entre les tentatives. Vous ne voulez évidemment pas continuer à essayer pour toujours, vous devez donc abandonner après un certain nombre de tentatives et lever une exception ou ignorer l'erreur. Comme ça:

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
}

À mon avis, un assistant comme celui-ci devrait être utilisé pour toutes les suppressions car des pannes parasites sont toujours possibles. Cependant, VOUS DEVEZ ADAPTER CE CODE À VOTRE CAS D'UTILISATION, pas simplement le copier à l'aveugle.

J'ai eu de fausses pannes pour un dossier de données interne généré par mon application, situé sous% LocalAppData%, donc mon analyse se présente comme suit:

1. Le dossier est contrôlé uniquement par mon application, et l'utilisateur n'a aucune raison valable d'aller marquer des choses en lecture seule ou inaccessibles dans ce dossier, donc je n'essaie pas de gérer ce cas.

2. Il n'y a rien de précieux créé par l'utilisateur, donc il n'y a aucun risque de supprimer de force quelque chose par erreur.

3. Étant un dossier de données interne, je ne m'attends pas à ce qu'il soit ouvert dans l'explorateur, au moins je ne ressens pas le besoin de gérer spécifiquement le cas (c'est-à-dire que je gère bien ce cas via le support).

4. Si toutes les tentatives échouent, je choisis d'ignorer l'erreur. Dans le pire des cas, l'application ne parvient pas à décompresser certaines ressources plus récentes, se bloque et invite l'utilisateur à contacter le support, ce qui est acceptable pour moi tant que cela ne se produit pas souvent. Ou, si l'application ne plante pas, elle laissera des anciennes données derrière moi, ce qui est encore acceptable pour moi.

5. J'ai choisi de limiter les tentatives à 500 ms (50 * 10). Il s'agit d'un seuil arbitraire qui fonctionne dans la pratique; Je voulais que le seuil soit suffisamment court pour que les utilisateurs ne tuent pas l'application, pensant qu'elle a cessé de répondre. D'un autre côté, une demi-seconde donne amplement de temps au délinquant pour terminer le traitement de mon dossier. À en juger par d'autres réponses SO qui trouvent parfois même Sleep(0)acceptables, très peu d'utilisateurs connaîtront jamais plus d'une seule nouvelle tentative.

6. Je réessaie toutes les 50 ms, ce qui est un autre nombre arbitraire. Je pense que si un fichier est en cours de traitement (indexé, vérifié) lorsque j'essaie de le supprimer, 50 ms est à peu près le bon moment pour s'attendre à ce que le traitement soit terminé dans mon cas. En outre, 50 ms est suffisamment petit pour ne pas entraîner de ralentissement notable; encore une fois, Sleep(0)semble être suffisant dans de nombreux cas, nous ne voulons donc pas trop tarder.

7. Le code réessaye toutes les exceptions d'E / S. Je ne m'attends normalement à aucune exception à l'accès à% LocalAppData%, j'ai donc choisi la simplicité et accepté le risque d'un retard de 500 ms en cas d'exception légitime. Je ne voulais pas non plus trouver un moyen de détecter l'exception exacte sur laquelle je veux réessayer.

Réponse Async Moderne

La réponse acceptée est tout simplement fausse, cela pourrait fonctionner pour certaines personnes car le temps nécessaire pour obtenir des fichiers à partir du disque libère tout ce qui bloquait les fichiers. Le fait est que cela se produit parce que les fichiers sont verrouillés par un autre processus / flux / action. Les autres réponses utilisent Thread.Sleep(Yuck) pour réessayer de supprimer le répertoire après un certain temps. Cette question doit être revisitée avec une réponse plus moderne.

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

Tests unitaires

Ces tests montrent un exemple de la façon dont un fichier verrouillé peut provoquer l' Directory.Deleteéchec de et comment la TryDeleteDirectoryméthode ci-dessus résout le problème.

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

Une chose importante qui doit être mentionnée (je l'ai ajoutée en tant que commentaire mais je n'y suis pas autorisé) est que le comportement de la surcharge est passé de .NET 3.5 à .NET 4.0.

Directory.Delete(myPath, true);

À partir de .NET 4.0, il supprime les fichiers dans le dossier lui-même mais PAS dans 3.5. Cela peut également être vu dans la documentation MSDN.

.NET 4.0

Supprime le répertoire spécifié et, si indiqué, tous les sous-répertoires et fichiers du répertoire.

.NET 3.5

Supprime un répertoire vide et, si indiqué, tous les sous-répertoires et fichiers du répertoire.

J'ai eu le même problème sous Delphi. Et le résultat final était que ma propre application bloquait le répertoire que je voulais supprimer. D'une manière ou d'une autre, le répertoire s'est verrouillé lorsque j'écrivais dessus (certains fichiers temporaires).

Le catch 22 était, j'ai fait un simple changement de répertoire vers son parent avant de le supprimer.

Je suis surpris que personne n'ait pensé à cette méthode simple non récursive, qui peut supprimer des répertoires contenant des fichiers en lecture seule, sans avoir besoin de changer l'attribut en lecture seule de chacun d'eux.

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

(Changez un peu pour ne pas déclencher une fenêtre cmd momentanément, qui est disponible partout sur Internet)

Vous pouvez reproduire l'erreur en exécutant:

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

Lorsque vous essayez de supprimer le répertoire 'b', il lève l'exception IOException "Le répertoire n'est pas vide". C'est stupide puisque nous venons de supprimer le répertoire 'c'.

D'après ma compréhension, l'explication est que le répertoire «c» est estampillé comme supprimé. Mais la suppression n'est pas encore validée dans le système. Le système a répondu que le travail est terminé, alors qu'en fait, il est toujours en cours de traitement. Le système attend probablement que l'explorateur de fichiers se concentre sur le répertoire parent pour valider la suppression.

Si vous regardez le code source de la fonction Supprimer ( http://referencesource.microsoft.com/#mscorlib/system/io/directory.cs ), vous verrez qu'il utilise la fonction native Win32Native.RemoveDirectory. Ce comportement de non-attente est noté ici:

La fonction RemoveDirectory marque un répertoire à supprimer à la fermeture. Par conséquent, le répertoire n'est supprimé que lorsque la dernière poignée du répertoire est fermée.

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

Dormir et réessayer est la solution. Cf la solution du ryascl.

J'ai eu ces problèmes d'autorisation étranges lors de la suppression des répertoires de profil utilisateur (dans C: \ Documents and Settings) malgré le fait de pouvoir le faire dans le shell de l'Explorateur.

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

Cela n'a aucun sens pour moi ce que fait une opération "fichier" sur un répertoire, mais je sais que cela fonctionne et cela me suffit!

Cette réponse est basée sur: https://stackoverflow.com/a/1703799/184528 . La différence avec mon code, c'est que nous ne récursions que de nombreux sous-répertoires et fichiers de suppression lorsque cela est nécessaire, un appel à Directory.Delete échoue lors d'une première tentative (ce qui peut se produire lorsque l'explorateur Windows regarde un répertoire).

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

Aucune des solutions ci-dessus n'a bien fonctionné pour moi. J'ai fini par utiliser une version modifiée de la solution @ryascl comme ci-dessous:

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

Est-il possible que vous ayez une condition de concurrence critique où un autre thread ou processus ajoute des fichiers au répertoire:

La séquence serait:

Processus Deleter A:

1. Vider le répertoire
2. Supprimez le répertoire (maintenant vide).

Si quelqu'un d'autre ajoute un fichier entre 1 et 2, alors peut-être que 2 lèverait l'exception répertoriée?

J'ai passé quelques heures à résoudre ce problème et d'autres exceptions avec la suppression du répertoire. C'est ma solution

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

Ce code a le petit retard, ce qui n'est pas important pour mon application. Mais attention, le délai peut être un problème pour vous si vous avez beaucoup de sous-répertoires dans le répertoire que vous souhaitez supprimer.

La suppression récursive du répertoire qui ne supprime pas les fichiers est certainement inattendue. Ma solution pour cela:

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

J'ai rencontré des cas où cela a aidé, mais généralement, Directory.Delete supprime les fichiers à l'intérieur des répertoires lors d'une suppression récursive, comme indiqué dans msdn .

De temps en temps, je rencontre ce comportement irrégulier également en tant qu'utilisateur de l'Explorateur Windows: Parfois, je ne peux pas supprimer un dossier (il pense que le message absurde est "accès refusé") mais lorsque j'explore et supprime les éléments inférieurs, je peux ensuite supprimer le supérieur articles aussi. Je suppose donc que le code ci-dessus traite d'une anomalie du système d'exploitation - pas d'un problème de bibliothèque de classe de base.

Le répertoire ou un fichier qu'il contient est verrouillé et ne peut pas être supprimé. Trouvez le coupable qui l'a verrouillé et voyez si vous pouvez l'éliminer.

Il semble qu'avoir le chemin ou le sous-dossier sélectionné dans l'Explorateur Windows soit suffisant pour bloquer une seule exécution de Directory.Delete (chemin, vrai), lançant une IOException comme décrit ci-dessus et mourant au lieu de démarrer l'Explorateur Windows dans un dossier parent et de procéder comme attendu.

J'ai eu ce problème aujourd'hui. Cela se produisait parce que j'avais Windows Explorer ouvert sur le répertoire qui essayait d'être supprimé, provoquant l'échec de l'appel récursif et donc l'IOException. Assurez-vous qu'il n'y a pas de descripteurs ouverts dans le répertoire.

De plus, MSDN est clair que vous n'avez pas à écrire votre propre récusion: http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx

J'ai eu ce même problème avec Windows Workflow Foundation sur un serveur de génération avec TFS2012. En interne, le flux de travail appelé Directory.Delete () avec l'indicateur récursif défini sur true. Il semble être lié au réseau dans notre cas.

Nous supprimions un dossier de dépôt binaire sur un partage réseau avant de le recréer et de le remplir à nouveau avec les derniers fichiers binaires. Toutes les autres versions échoueraient. Lors de l'ouverture du dossier de dépôt après une génération ayant échoué, le dossier était vide, ce qui indique que tous les aspects de l'appel Directory.Delete () ont réussi, à l'exception de la suppression du répertoire réel.

Le problème semble être dû à la nature asynchrone des communications de fichiers réseau. Le serveur de génération a dit au serveur de fichiers de supprimer tous les fichiers et le serveur de fichiers a signalé que oui, même s'il n'était pas complètement terminé. Ensuite, le serveur de génération a demandé que le répertoire soit supprimé et le serveur de fichiers a rejeté la demande car il n'avait pas complètement terminé la suppression des fichiers.

Deux solutions possibles dans notre cas:

• Construisez la suppression récursive dans notre propre code avec des retards et des vérifications entre chaque étape
• Réessayez jusqu'à X fois après une IOException, ce qui donne un délai avant de réessayer

Cette dernière méthode est rapide et sale mais semble faire l'affaire.

Cela est dû à FileChangesNotifications.

Cela se produit depuis ASP.NET 2.0. Lorsque vous supprimez un dossier dans une application, il est redémarré . Vous pouvez le voir vous-même, à l'aide de la surveillance de la santé ASP.NET .

Ajoutez simplement ce code à votre web.config / configuration / system.web:

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

Après cette vérification Windows Log -> Application. Que se passe-t-il:

Lorsque vous supprimez un dossier, s'il existe un sous-dossier, Delete(path, true)supprimez d'abord le sous-dossier. Il suffit que FileChangesMonitor connaisse la suppression et fermez votre application. Pendant ce temps, votre répertoire principal n'est pas encore supprimé. Voici l'événement de Log:

Delete() n'a pas terminé son travail et parce que l'application est en cours de fermeture, il déclenche une exception:

Lorsque vous n'avez aucun sous-dossier dans un dossier que vous supprimez, Delete () supprime simplement tous les fichiers et ce dossier, l'application redémarre également, mais vous ne recevez aucune exception , car le redémarrage de l'application n'interrompt rien. Mais vous perdez toutes les sessions en cours, l'application ne répond pas aux demandes lors du redémarrage, etc.

Et maintenant?

Il existe des solutions et des ajustements pour désactiver ce comportement, Directory Junction , Turning Off FCN with Registry , Stopping FileChangesMonitor using Reflection (puisqu'il n'y a pas de méthode exposée) , mais ils ne semblent pas tous avoir raison, car FCN est là pour un raison. Il s'occupe de la structure de votre application , qui n'est pas la structure de vos données . La réponse courte est: placez les dossiers que vous souhaitez supprimer en dehors de votre application. FileChangesMonitor ne recevra aucune notification et votre application ne sera pas redémarrée à chaque fois. Vous n'aurez aucune exception. Pour les rendre visibles sur le Web, il existe deux manières:

1. Créez un contrôleur qui gère les appels entrants et sert ensuite les fichiers en lisant à partir du dossier en dehors d'une application (en dehors de wwwroot).

2. Si votre projet est volumineux et que les performances sont les plus importantes, configurez un serveur Web petit et rapide séparé pour diffuser du contenu statique. Ainsi vous laisserez à IIS son métier spécifique. Il peut s'agir de la même machine (mangouste pour Windows) ou d'une autre machine (nginx pour Linux). Bonne nouvelle, vous n'avez pas à payer de licence Microsoft supplémentaire pour configurer un serveur de contenu statique sur Linux.

J'espère que cela t'aides.

Comme mentionné ci-dessus, la solution "acceptée" échoue sur les points d'analyse - pourtant les gens la marquent toujours (???). Il existe une solution beaucoup plus courte qui reproduit correctement la fonctionnalité:

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

Je sais, ne gère pas les cas d'autorisations mentionnés plus tard, mais à toutes fins utiles, FAR BETTER fournit les fonctionnalités attendues du répertoire original / stock.Delete () - et avec beaucoup moins de code aussi .

Vous pouvez poursuivre le traitement en toute sécurité, car l'ancien répertoire sera hors de portée ... même s'il n'est pas parti parce que le `` système de fichiers est toujours en train de rattraper son retard '' (ou toute autre excuse que MS a donnée pour fournir une fonction cassée) .

Comme avantage, si vous savez que votre répertoire cible est grand / profond et que vous ne voulez pas attendre (ou déranger avec des exceptions), la dernière ligne peut être remplacée par:

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

Vous êtes toujours en sécurité pour continuer à travailler.

Ce problème peut apparaître sous Windows lorsqu'il existe des fichiers dans un répertoire (ou dans n'importe quel sous-répertoire) dont la longueur de chemin d'accès est supérieure à 260 symboles.

Dans de tels cas, vous devez supprimer \\\\?\C:\mydirau lieu de C:\mydir. À propos de la limite de 260 symboles, vous pouvez lire ici .

J'ai résolu avec cette technique millénaire (vous pouvez laisser le fil. Dormir tout seul dans la prise)

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

Si le répertoire actuel de votre application (ou de toute autre application) est celui que vous essayez de supprimer, il ne s'agira pas d'une erreur de violation d'accès mais un répertoire n'est pas vide. Assurez-vous que ce n'est pas votre propre application en changeant le répertoire courant; assurez-vous également que le répertoire n'est pas ouvert dans un autre programme (par exemple, Word, Excel, Total Commander, etc.). La plupart des programmes seront enregistrés dans le répertoire du dernier fichier ouvert, ce qui provoquerait cela.

en cas de fichiers réseau, Directory.DeleteHelper (récursif: = true) peut provoquer une exception IOException causée par le retard de la suppression du fichier

Je pense qu'il y a un fichier ouvert par un flux dont vous n'êtes pas au courant. J'ai eu le même problème et je l'ai résolu en fermant tous les flux qui pointaient vers le répertoire que je voulais supprimer.

Cette erreur se produit si un fichier ou un répertoire est considéré comme en cours d'utilisation. C'est une erreur trompeuse. Vérifiez si vous avez des fenêtres d'explorateur ou des fenêtres de ligne de commande ouvertes sur n'importe quel répertoire de l'arborescence ou un programme qui utilise un fichier dans cette arborescence.

J'ai résolu une instance possible du problème déclaré lorsque les méthodes étaient asynchrones et codées comme ceci:

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

Avec ça:

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

Conclusion? Il y a un aspect asynchrone à se débarrasser de la poignée utilisée pour vérifier l'existence dont Microsoft n'a pas pu parler. C'est comme si la méthode asynchrone dans une instruction if avait l'instruction if agissant comme une instruction using.

Vous n'avez pas besoin de créer et de méthode supplémentaire pour la récursivité ou de supprimer des fichiers dans le dossier supplémentaire. Tout cela se fait automatiquement en appelant

DirectoryInfo.Delete ();

Les détails sont ici .

Quelque chose comme ça fonctionne assez bien:

  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
    }

passer true comme variable pour supprimer la méthode supprimera également les sous-fichiers et le sous-dossier contenant les fichiers.

Aucune des réponses ci-dessus n'a fonctionné pour moi. Il semble que l'utilisation de ma propre application DirectoryInfosur le répertoire cible le faisait rester verrouillé.

Forcer la collecte des ordures semble résoudre le problème, mais pas tout de suite. Quelques tentatives de suppression si nécessaire.

Notez le Directory.Existscar il peut disparaître après une exception. Je ne sais pas pourquoi la suppression a été retardée pour moi (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.");

ajouter vrai dans le deuxième paramètre.

Directory.Delete(path, true);

Cela supprimera tout.