La forma más rápida de eliminarlos de ese directorio es sacarlos de allí, después de eso simplemente elimínelos en segundo plano:
mkdir ../.tmp_to_remove
mv -- * ../.tmp_to_remove
rm -rf ../.tmp_to_remove &
Esto supone que su directorio actual no es el nivel superior de alguna partición montada (es decir, que ../.tmp_to_remove está en el mismo sistema de archivos).
El -- después de mv (como lo editó Stéphane) es necesario si tiene algún nombre de archivo/directorio que comience con un - .
Lo anterior elimina los archivos de su directorio actual en una fracción de segundo, ya que no tiene que manejar los subdirectorios de forma recursiva. La eliminación real del árbol del sistema de archivos lleva más tiempo, pero dado que está fuera del camino, su eficiencia real no debería importar mucho.
rsync es sorprendentemente rápido y simple. Primero debe crear un directorio vacío,
mkdir emptydir rsync -a --delete emptydir/ yourdirectory/
yourdirectory/ es el directorio desde donde desea eliminar los archivos.
Un problema con rm -rf * , o su equivalente más correcto rm -rf -- * es que el shell primero tiene que enumerar todos los archivos (no ocultos) en el directorio actual, ordenarlos y pasarlos a rm , que si la lista de archivos en el directorio actual es grande agregará una sobrecarga adicional innecesaria e incluso podría fallar si la lista de archivos es demasiado grande.
Normalmente, harías rm -rf . en su lugar (lo que también tendría el beneficio de eliminar archivos ocultos también). Pero la mayoría rm las implementaciones, incluidas todas las compatibles con POSIX, se negarán a hacerlo. La razón es que algunos shells (incluidos todos los POSIX) tienen esa característica incorrecta que la expansión de .* glob incluiría . y .. . Lo que significaría que rm -rf .* eliminaría el directorio actual y principal, por lo que rm se ha modificado para evitar esa característica incorrecta de esos proyectiles.
Algunas conchas como pdksh (y otros derivados de Forsyth shell), zsh o fish no tengas esa falla. zsh tiene un rm incorporado que puede habilitar con autoload zsh/files que, desde zsh de .* no incluye . ni .. funciona bien con rm -rf . . Entonces en zsh , puedes hacer:
autoload zsh/files
rm -rf .
En Linux, puede hacer:
rm -rf /proc/self/cwd/
para vaciar el directorio actual o:
rm -rf /dev/fd/3/ 3< some/dir
para vaciar un directorio arbitrario.
(tenga en cuenta el final / )
En sistemas GNU, puede hacer:
find . -delete
Ahora, si el directorio actual solo tiene unas pocas entradas y la mayor parte de los archivos están en subdirectorios, eso no hará una diferencia significativa y rm -rf -- * probablemente será lo más rápido que puedas conseguir. Se espera para rm -rf (o cualquier cosa que elimine todos los archivos) sea costoso, ya que significa leer el contenido de todos los directorios y llamar a unlink() en cada entrada. unlink() en sí mismo puede ser bastante costoso, ya que implica modificar el inodo del archivo eliminado, el directorio que contiene el archivo y algún mapa del sistema de archivos u otras áreas que están libres.
rm y find (al menos las implementaciones de GNU) ya ordenan la lista de archivos por número de inodo en cada directorio, lo que puede marcar una gran diferencia en términos de rendimiento en los sistemas de archivos ext4, ya que reduce la cantidad de cambios en los dispositivos de bloques subyacentes cuando son consecutivos (o cercanos). entre sí) los inodos se modifican en secuencia.
rsync ordena los archivos por nombre, lo que podría reducir drásticamente el rendimiento a menos que el orden por nombre coincida con el orden por número (como cuando los archivos se han creado a partir de una lista ordenada de nombres de archivo).
Una razón por la que rsync puede ser más rápido en algunos casos es que no parece tomar precauciones de seguridad para evitar condiciones de carrera que podrían hacer que descienda al directorio incorrecto si un directorio se reemplazó con un enlace simbólico mientras funciona como rm o find hacer.
Para optimizar un poco más:
Si conoce la profundidad máxima de su árbol de directorios, puede pasarlo a find :
find . -maxdepth 3 -delete
Eso ahorra find tener que probar y leer el contenido de los directorios en profundidad 3.