¿Por qué la recursividad no sube con rm?

Me pregunto acerca de la dirección de la recursión en general y específicamente de la empresa.

La recursividad rm solo funciona hacia abajo ¿correcto?

En ejecución: sudo rm -R *.QTFSeliminará todos los archivos * .QTFS en el directorio actual y sus hijos, ¿correcto?

El directorio actual como se muestra en ls -lhatambién contiene .y ..enlaces por la falta de una mejor palabra, entonces, ¿por qué la recursividad no sigue estos hacia arriba en el árbol de directorios? ¿Hay un límite artificial en la aplicación rm, o .y ..no son cosas reales?

recursive

Debido a la raíz, y la locura, de esa manera mentiras ...

— jasonwryan

Relacionado: ¿'rm. *' Alguna vez elimina el directorio padre?

— Stéphane Chazelas

Bueno, para una anécdota interesante ... Ejecuté rm -rf en algunos subdirectorios de aspecto inocente en un punto solo para encontrar para mi horror que un usuario tenía cosas vinculadas allí a una corriente ascendente muy importante, que luego procedió a comer. Sí, tenía copias de seguridad actuales y no se perdieron datos, pero que sea una historia de advertencia ... :-)

— Brian Knoblauch

@BrianKnoblauch, ¿qué daño podría hacerse al eliminar un enlace duro? No entendí el punto de tu historia ...

— Alexey

@Alexey El punto es que el enlace duro en sí no se eliminó. Se recursed abajo en el directorio relacionado duro, que estaba vinculado a un punto más alto en el sistema de archivos, por lo que empezó a comer de datos de todos ...

— Brian Knoblauch

Respuestas:

rm la recursividad solo funciona hacia abajo ¿correcto?

rm -r x yeliminará xy ytodo lo que esté dentro de ellos (si son directorios), pero no sus padres ni nada fuera de ellos.

En ejecución: sudo rm -R *.QTFSeliminará todos los archivos * .QTFS en el directorio actual y sus hijos, ¿correcto?

No. Eliminará todos los archivos nombrados *.QTFS, cualquier archivo recursivamente dentro de los directorios llamados *.QTFS, y esos directorios mismos. Si desea ese otro comportamiento de eliminación, use find -delete.

El directorio actual como se muestra en ls -lhatambién contiene .y ..enlaces por la falta de una mejor palabra, entonces, ¿por qué la recursividad no sigue estos hacia arriba en el árbol de directorios? ¿Hay un límite artificial en la aplicación rm, o .y ..no son cosas reales?

Es un límite artificial de rm.

Sin embargo, no es realmente tan artificial: es la única forma en que podría funcionar. Si se rmsiguen los ..enlaces principales , cada rm -reliminaría todos los archivos del sistema, siguiendo todos los ..enlaces hasta el final /. rmve las entradas ..y .en cada directorio cuando enumera el contenido y las ignora explícitamente por ese motivo.

Puedes probar eso tú mismo, de hecho. Ejecutar rm -r .y la mayoría de las rmimplementaciones se negarán a actuar, informando un error explícitamente:

$ rm -r .
rm: refusing to remove ‘.’ or ‘..’ directory: skipping ‘.’

(ese mensaje es de GNUrm ; otros son similares). Cuando encuentra estas entradas implícitamente, en lugar de como argumentos explícitos, simplemente las ignora y continúa. POSIX requiere ese comportamiento . En GNU rmy muchos de los BSD, es proporcionado automáticamente por la fts_readfamilia de funciones de jerarquía transversal.

o .y ..no son cosas reales?

.y generalmente.. son entradas de directorio reales, aunque eso es específico del sistema de archivos. Casi siempre se presentarán como si fueran entradas reales de todos los códigos de usuario, independientemente. Muchas piezas de software (no solo ) hacen un caso especial de su comportamiento para atrapar o prevenir una recursión desbocada o indeseable.rm

— Michael Homer
fuente

Para cualquiera que busque pruebas (o simplemente esté interesado), eche un vistazo a cómo se implementa esto en GNU coreutils .

— Chris Hayes

@ChrisHayes El enlace gitweb equivalente está en la respuesta. El caso recursivo real está en la fts_readimplementación, sin embargo, ese es solo para argumentos de línea de comandos.

— Michael Homer

@MichaelHomer Oh wow, así es. Ese color de enlace no se destaca en este esquema SE. Mi error.

— Chris Hayes

Esta respuesta es correcta pero también un poco imprecisa. rmni siquiera ve *.QTFSporque se ha expandido globalmente en los nombres de archivo por bash antes de que se invoque el binario rm. La respuesta de @ tobyink señala eso.

— Daenyth

Como anotación al margen, los .y ..conducta caso especial se dice que son la causa de la existencia dotfiles

— mgarciaisaia

Además de lo que escribió Michael Homer, hay otro factor que dificulta la recurrencia accidental al directorio principal.

Vaya a su directorio de inicio y escriba algo como:

echo *s*

Verá que muestra una lista de archivos y directorios que contienen la letra "s". Sin embargo, no se muestran archivos que comiencen con un punto inicial. Para mostrarlos, puede usar:

echo .*s*

Esto se debe a que el shell se niega a expandirse *para abarcar un punto inicial. Esto significa que:

rm -fr *

No recurrirá a ...

— tobyink
fuente