Le moyen le plus rapide de les supprimer de ce répertoire est de les déplacer hors de là, après cela, supprimez-les simplement en arrière-plan :
mkdir ../.tmp_to_remove
mv -- * ../.tmp_to_remove
rm -rf ../.tmp_to_remove &
Cela suppose que votre répertoire actuel n'est pas le niveau supérieur d'une partition montée (c'est-à-dire que ../.tmp_to_remove est sur le même système de fichiers).
Le -- après mv (tel que modifié par Stéphane) est nécessaire si vous avez des noms de fichiers/répertoires commençant par un - .
Ce qui précède supprime les fichiers de votre répertoire actuel en une fraction de seconde, car il n'a pas à gérer récursivement les sous-répertoires. La suppression réelle de l'arborescence du système de fichiers prend plus de temps, mais comme elle est à l'écart, son efficacité réelle ne devrait pas avoir beaucoup d'importance.
rsync est étonnamment rapide et simple. Vous devez d'abord créer un répertoire vide,
mkdir emptydir rsync -a --delete emptydir/ yourdirectory/
yourdirectory/ est le répertoire d'où vous voulez supprimer les fichiers.
Un problème avec rm -rf * , ou son équivalent plus correct rm -rf -- * est que le shell doit d'abord lister tous les fichiers (non cachés) du répertoire courant, les trier et les passer à rm , qui, si la liste des fichiers dans le répertoire actuel est grande, va ajouter une surcharge supplémentaire inutile, et pourrait même échouer si la liste des fichiers est trop grande.
Normalement, vous feriez rm -rf . à la place (ce qui aurait également l'avantage de supprimer également les fichiers cachés). Mais la plupart rm les implémentations, y compris toutes celles conformes à POSIX, refuseront de le faire. La raison en est que certains shells (y compris tous ceux de POSIX) ont ce défaut que l'expansion de .* glob inclurait . et .. . Ce qui signifierait que rm -rf .* supprimerait le répertoire actuel et parent, donc rm a été modifié pour contourner cette mauvaise fonctionnalité de ces coques.
Certains shells comme pdksh (et autres dérivés du shell Forsyth), zsh ou fish n'ont pas ce défaut. zsh a un rm intégré que vous pouvez activer avec autoload zsh/files que, depuis zsh est .* n'inclut pas . ni .. fonctionne bien avec rm -rf . . Donc en zsh , vous pouvez faire :
autoload zsh/files
rm -rf .
Sous Linux, vous pouvez faire :
rm -rf /proc/self/cwd/
pour vider le répertoire en cours ou :
rm -rf /dev/fd/3/ 3< some/dir
pour vider un répertoire arbitraire.
(notez le / final )
Sur les systèmes GNU, vous pouvez faire :
find . -delete
Maintenant, si le répertoire actuel ne contient que quelques entrées et que la majeure partie des fichiers se trouve dans des sous-répertoires, cela ne fera pas de différence significative et rm -rf -- * sera probablement le plus rapide que vous puissiez obtenir. Il est attendu pour rm -rf (ou tout ce qui supprime tous les fichiers) coûte cher car cela signifie lire le contenu de tous les répertoires et appeler le unlink() à chaque entrée. unlink() lui-même peut être assez coûteux car il implique de modifier l'inode du fichier supprimé, le répertoire contenant le fichier et une carte du système de fichiers ou d'autres zones libres.
rm et find (au moins les implémentations GNU) trient déjà la liste des fichiers par numéro d'inode dans chaque répertoire, ce qui peut faire une énorme différence en termes de performances sur les systèmes de fichiers ext4 car cela réduit le nombre de modifications apportées aux périphériques de bloc sous-jacents lorsqu'ils sont consécutifs (ou proches les uns aux autres) les inodes sont modifiés en séquence.
rsync trie les fichiers par nom, ce qui pourrait réduire considérablement les performances à moins que l'ordre par nom ne corresponde à l'ordre par inum (comme lorsque les fichiers ont été créés à partir d'une liste triée de noms de fichiers).
Une raison pour laquelle rsync peut être plus rapide dans certains cas, c'est qu'il ne semble pas prendre de précautions de sécurité pour éviter les conditions de concurrence qui pourraient le faire descendre dans le mauvais répertoire si un répertoire a été remplacé par un lien symbolique alors qu'il fonctionne comme rm ou find faire.
Pour optimiser un peu plus :
Si vous connaissez la profondeur maximale de votre arborescence de répertoires, vous pouvez la passer à find :
find . -maxdepth 3 -delete
Cela économise find devoir essayer de lire le contenu des répertoires en profondeur 3.