Vous n'avez pas besoin de longs chemins d'accès si vous entrez chdir
dans le répertoire et utilisez simplement des chemins d'accès relatifs à rmdir
.
Ou, si vous avez un shell POSIX installé, ou portez-le à l’équivalent DOS:
# untested code, didn't bother actually testing since the OP already solved the problem.
while [ -d Folder1 ]; do
mv Folder1/Folder1/Folder1/Folder1 tmp # repeat more times to work in larger batches
rm -r Folder1 # remove the first several levels remaining after moving the main tree out
# then repeat to end up with the remaining big tree under the original name
mv tmp/Folder1/Folder1/.../Folder1 Folder1
rm -r tmp
done
(Utiliser une variable shell pour savoir où vous l'avez renommé pour la condition de boucle constitue l'autre alternative pour dérouler la boucle comme je l'ai fait ici.)
Cela évite la surcharge de temps processeur de la solution de KenD, qui oblige le système d'exploitation à parcourir l'arborescence du haut au n
troisième niveau à chaque fois qu'un nouveau niveau est ajouté, en vérifiant les autorisations, etc. Il a donc une sum(1, n) = n * (n-1) / 2 = O(n^2)
complexité temporelle. Les solutions qui réduisent une partie du début de la chaîne doivent l'être O(n)
, sauf si Windows doit traverser une arborescence lors du changement de nom de son répertoire parent. (Linux / Unix non.) Des solutions chdir
allant jusqu'au bas de l'arborescence et utilisant des chemins relatifs à partir de là, supprimant les répertoires lors de la chdir
sauvegarde, devraient également l'être O(n)
, à condition que le système d'exploitation n'ait pas besoin de vérifier tous vos fichiers. répertoires parents chaque appel système, lorsque vous faites quelque chose sur CD.
find Folder1 -depth -execdir rmdir {} +
exécutera rmdir tant qu’il sera CDé dans le répertoire le plus profond. Ou en fait, l' -delete
option de find fonctionne sur les répertoires et implique -depth
. Alors find Folder1 -delete
devrait faire exactement la même chose, mais plus rapidement. Ouais, GNU find sur Linux descend en parcourant un répertoire, CD-ROM dans des sous-répertoires avec des chemins relatifs, puis rmdir
avec un chemin relatif, puis chdir("..")
. Il ne réanalyse pas les répertoires lors d'une ascension, il consomme donc de la O(n)
RAM.
C'était vraiment une approximation: strace
montre qu'il utilise EFFECTIVEMENT unlinkat(AT_FDCWD, "tmp", AT_REMOVEDIR)
, open("..", O_DIRECTORY|...)
et fchdir(the fd from opening the directory)
, avec un tas d' fstat
appels 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 est en cours d'exécution.
edit: Juste pour le plaisir, j’ai essayé ceci sous GNU / Linux (Ubuntu 14.10, sur un processeur Core2Duo de première génération à 2,4 GHz, sur un système de fichiers XFS sur un lecteur WD 2.5TB Green Power (WD25EZRS)).
time mkdir -p $(perl -e 'print "annoyingfoldername/" x 2000, "\n"')
real 0m1.141s
user 0m0.005s
sys 0m0.052s
find annoyingfoldername/ | wc
2000 2000 38019001 # 2k lines / 2k words / 38M characters of text
ll -R annoyingfoldername
... eventually
ls: cannot access ./annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername: File name too long
total 0
?????????? ? ? ? ? ? annoyingfoldername
time find annoyingfoldername -delete
real 0m0.054s
user 0m0.004s
sys 0m0.049s
# about the same for normal rm -r,
# which also didn't fail due to long path names
(mkdir -p crée un répertoire et tous les composants de chemin manquants).
Oui, vraiment 0,05 seconde pour 2k opérations rmdir. xfs est assez bon pour regrouper les opérations de métadonnées dans le journal, car elles ont corrigé les opérations de métadonnées comme étant lentes il y a 10 ans.
Sur ext4, create prenait 0m0.279s, supprimer avec find prenait toujours 0m0.074s.
/MIR
plutôt: celaROBOCOPY /MIR C:\temp\EmptyDirectory C:\Storage\Folder1
peut aussi valoir la peine de courir unchkdsk
peu pour rire.