Suppression d'un dossier (apparemment) récursif à l'infini

Peut être un point de jonction récursif. Une telle chose peut être créée avec junction, un utilitaire de fichiers et de disque de Sysinternals.

mkdir c:\Hello
junction c:\Hello\Hello c:\Hello

Et vous pouvez maintenant descendre sans fin dans c:\Hello\Hello\Hello.... (enfin jusqu'à ce que MAX_PATH soit atteint, 260 caractères pour la plupart des commandes mais 32,767 caractères pour certaines fonctions de l'API Windows).

Une liste de répertoire montre qu'il s'agit d'un point de jonction :

C:\>dir c:\hello
 Volume in drive C is DR1
 Volume Serial Number is 993E-B99C

 Directory of c:\hello

12/02/2015  08:18 AM    

Pour supprimer, utilisez l'utilitaire de point de jonction :

junction -d c:\Hello\Hello

Pas une réponse, mais je n'ai pas assez de réputation pour un commentaire.

J'ai une fois résolu ce problème sur un disque FAT16 alors énorme de 500 Mo sur un système MS-DOS. J'ai utilisé DOS debug pour faire une extraction manuelle et analyser le tableau de répertoire. J'ai alors basculé un bit pour marquer le répertoire récursif comme supprimé. Mon exemplaire de la référence DOS 'Programmers' de Dettman et Wyatt m'a montré le chemin.

Je suis toujours excessivement fier de cela. Je serais étonné et terrifié s'il y avait un outil généraliste ayant un tel pouvoir sur les volumes FAT32 ou NTFS. La vie était plus simple à l'époque.

Java peut également gérer des chemins de fichiers longs. Et il peut le faire beaucoup plus rapidement aussi. Ce code (que j'ai copié de la documentation de l'API Java) supprimera une structure de répertoire de 1600 niveaux de profondeur en environ 1 seconde (sous Windows 7, Java 8.0) et sans risque de débordement de la pile car il n'utilise pas réellement de récursion.

import java.nio.file.*;
import java.nio.file.attribute.*;
import java.io.*;

public class DeleteDir {

  static void deleteDirRecur(Path dir) throws IOException {
    Files.walkFileTree(dir, new SimpleFileVisitor() {
         @Override
         public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
             throws IOException
         {
             Files.delete(file);
             return FileVisitResult.CONTINUE;
         }
         @Override
         public FileVisitResult postVisitDirectory(Path dir, IOException e)
             throws IOException
         {
             if (e == null) {
                 Files.delete(dir);
                 return FileVisitResult.CONTINUE;
             } else {
                 throw e;
             }
         }
     });
  }

  public static void main(String[] args) throws IOException {
    deleteDirRecur(Paths.get("C:/Storage/Folder1"));
  }
}

Vous n'avez pas besoin de longs chemins d'accès si vous chdir dans le répertoire et utilisez simplement des chemins relatifs vers rmdir.

Ou, si vous avez un shell POSIX installé, ou si vous portez ceci à l'équivalent DOS :

# code non testé, je n'ai pas pris la peine de tester puisque l'OP a déjà résolu le problème.

while [ -d Folder1 ]; do
    mv Folder1/Folder1/Folder1/Folder1  tmp # répète plus de fois pour travailler en plus gros lots
    rm -r Folder1     # enlever les premiers niveaux restants après avoir déplacé l'arborescence principale
    # puis répéter pour finir avec l'arbre restant sous le nom d'origine
    mv tmp/Folder1/Folder1/.../Folder1 Folder1 
    rm -r tmp
done

(Utiliser une variable d'environnement pour suivre où vous l'avez renommée pour la condition de la boucle est l'autre alternative à dérouler la boucle comme je l'ai fait là.)

Cela évite les surdébits CPU de la solution de KenD, qui force le système d'exploitation à parcourir l'arbre du haut au niveau n à chaque fois qu'un nouveau niveau est ajouté, vérifiant les permissions etc. Donc cela a une complexité temporelle de sum(1, n) = n * (n-1) / 2 = O(n^2). Les solutions qui suppriment un morceau du début de la chaîne devraient être O(n), sauf si Windows doit parcourir un arbre lors du renommage de son répertoire parent. (Linux/Unix non plus.) Les solutions qui font chdir jusqu'au bas de l'arbre et utilisent des chemins relatifs à partir de là, en supprimant les répertoires pendant qu'ils remontent, devraient également être O(n), en supposant que le système d'exploitation n'ait pas besoin de vérifier tous vos répertoires parent à chaque appel système, lorsque vous effectuez des tâches tout en étant changeé quelque part.

find Folder1 -depth -execdir rmdir {} + exécutera rmdir tout en étant changé dans le répertoire le plus profond. Ou en fait, l'option -delete de find fonctionne sur les répertoires, et implique -depth. Donc find Folder1 -delete devrait faire exactement la même chose, mais plus rapidement. Oui, GNU find sur Linux descend en balayant un répertoire, en se changeant en sous-répertoires avec des chemins relatifs, puis rmdir avec un chemin relatif, puis chdir(".."). Il ne rescane pas les répertoires en montant, donc il consommerait O(n) de RAM.

C'était vraiment une approximation : strace montre qu'il utilise ACTUELLEMENT unlinkat(AT_FDCWD, "tmp", AT_REMOVEDIR), open("..", O_DIRECTORY|...), et fchdir(le fd de l'ouverture du répertoire), avec un tas d'appels de fstat mélangés, aussi. Mais l'effet est le même si l'arborescence de répertoires n'est pas modifiée pendant que find fonctionne.

modifier : Juste pour rire, j'ai essayé cela sur GNU/Linux (Ubuntu 14.10, sur un CPU Core2Duo de première génération de 2,4GHz, sur un système de fichiers XFS sur un disque WD 2.5TB Green Power (WD25EZRS)).

time mkdir -p $(perl -e 'print "annoyingfoldername/" x 2000, "\n"')

réel    0m1.141s
utilisateur    0m0.005s
système     0m0.052s

find annoyingfoldername/ | wc
   2000    2000 38019001  # 2k lignes / 2k mots / 38M caractères de texte

ll -R annoyingfoldername
... eventually
ls: ne peut accéder à ./annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfold...

time find annoyingfoldername -delete

réel    0m0.054s
utilisateur    0m0.004s
système     0m0.049s

# environ la même chose pour rm -r normal,
# qui n'a pas échoué non plus en raison de noms de chemin trop longs

(mkdir -p crée un répertoire et tous les composants de chemin manquants).

Oui, vraiment 0,05 secondes pour 2k opérations rmdir. xfs est très bon pour regrouper ensemble les opérations de métadonnées dans le journal, puisqu'ils ont corrigé les opérations de métadonnées lentes il y a environ 10 ans.

Sur ext4, la création a pris 0m0.279s, la suppression avec find a quand même pris 0m0.074s.