rsync 'no puede eliminar los errores del directorio no vacío', incluso con la opción --force

28

Al ejecutar este comando:

$ sudo rsync -r --delete --force --checksum --exclude=uploads /data/prep/* /data/app/

Estoy obteniendo el siguiente resultado:

cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor
cannot delete non-empty directory: html/js/ckeditor/_source/plugins
cannot delete non-empty directory: html/js/ckeditor/_source/plugins
cannot delete non-empty directory: html/js/ckeditor/_source
cannot delete non-empty directory: html/js/ckeditor/_samples
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor

Al leerlo man rsync, tuve la impresión de que la --forceopción le diría a rsync que elimine estos directorios no vacíos, que es el resultado deseado.

Árbitro:

--force                 force deletion of dirs even if not empty

¿Cómo puedo modificar el comando para eliminar los directorios no vacíos?

Estoy usando rsync versión 3.0.8, en Gentoo Base System versión 2.0.3, en caso de que sea relevante.

Actualización: se agregó sudoal comando para dejar en claro que este no es un problema de permisos de archivos.

— tommarshall
fuente

¿Qué sistema de archivos es el destino? ¿El sistema de archivos necesita reparación?

— Marcus Downing

El sistema de archivos es ext3. Es posible que el sistema de archivos pueda necesitarse o repararse. Lo haré fscken la próxima oportunidad y actualizaré con los resultados.

— tommarshall

Acabo fsckde arreglar el sistema y este problema aún está presente.

— tommarshall

39

¿Intentaste agregar --delete-excluded?

Si elimina un directorio en sus carpetas excluidas en el lado "remoto", rsync --deleteno eliminará la carpeta excluida en su sitio "local".

— Martin Höger
fuente

Hubo una carpeta llamada uploadsen los html/js/ckeditor/_source/plugins/uicolor/yui, html/js/ckeditor/_samplesy html/js/ckeditor/plugins/uicolor/yuidirectorios. Gracias por tu ayuda.

— tommarshall

si usa --delete-excludedpero aún desea excluir ciertos archivos / directorios de la eliminación, puede poner estos archivos / directorio en --filter 'protect some_dir/', por ejemplo:rsync -ac --delete --delete-excluded --exclude '*.html' --filter 'protect .git/' . /target/destination/

— alexandre1985

6

Aquí hay posibles fuentes de este problema:

(1) Este error puede ser el resultado de la opción -b (--backup). Esta opción creará una copia de seguridad de cada archivo eliminado, agregando una tilde ( ~ ) en su nombre de archivo. (Esto me confundió, ya que el nombre del archivo es claramente una copia de seguridad, pero el nombre del directorio no lo es, ya que no puede ver la tilde).

Para verificar si este es el mismo caso, lea su directorio de destino en el nivel más profundo y verifique si hay algún archivo final de tilde (~). Tenga en cuenta que estos nombres de archivos adjuntos tilde son invisibles en algún sistema de exploración de archivos común, por lo que es posible que no los vea.

Para resolver este caso, prefiera la opción --backup-dir = DIR, por ejemplo --backup-dir = .rsync_bak.

(2) La opción --exclude puede tener los mismos resultados. Lo que posiblemente está sucediendo en su caso. El sistema de patrones es poderoso, pero puede ser engañoso. Por ejemplo, si escribe --exclude = '* ~', esto omitirá todos los archivos finales de tilde, resultando exactamente como en el caso (1) anterior.

de la página del manual de rsync:

si el patrón comienza con un / entonces está anclado a un punto particular en la jerarquía de archivos, de lo contrario se compara con el final del nombre de ruta

Si si escribe --exclude = uploads, esto excluirá todos los archivos llamados "updloads", en cualquier nivel de su árbol de archivos.

Verifique si hay un archivo llamado "uploads" dentro de sus directorios incapaces de eliminar.

La solución sería cambiar "--exclude = uploads" a "--exclude = uploads /"

— usuario3586623
fuente

0

En mi configuración ((la fuente es el formato Ubuntu tipo ext4 para apuntar al tipo Western Digital fuseblk) funciona con:

rsync -a -v --progress --modify-window=1 -c -b -i -s -m --del -vv --ignore-errors --chmod=ugo=rwx --delete --delete-excluded  --exclude='*~'  --exclude='.*' --backup-dir=.rsync_bak /home/test /media/user/usbHDD

— Consuegro
fuente

2

¿Qué parte de esto realmente resuelve el problema?

— Michael Hampton

0

Use reglas en archivos de filtro en lugar de --exclude. Estos le permiten marcar las exclusiones como "persistentes", lo que le permitirá eliminar directorios no vacíos que contienen archivos excluidos.

Vea esta respuesta para más detalles.

— mivk
fuente

-1

Un directorio debe estar vacío para que pueda eliminarlo, el sistema de archivos normalmente lo requiere.

Por lo tanto, normalmente rsynco rmrecursivamente eliminaría todo el contenido primero y solo luego eliminaría el directorio ahora vacío.

Si el usuario actual no es el propietario de todos los archivos, los permisos del sistema de archivos no le permitirán eliminar esos archivos. Como no se eliminarán, el directorio no se vaciará y la eliminación fallará.

Mi primera suposición sería que algunos archivos en esos directorios son propiedad de otro usuario, por ejemplo, los usuarios de apache o de nadie.

— HBruijn
fuente

Gracias. Los archivos dentro de los directorios son propiedad de un usuario dentro del grupo apache, sin embargo, acabo de intentar ejecutar este comando como ese usuario y obtuve los mismos errores.

— tommarshall

Además, si se tratara de un problema de permisos de archivos, esperaría ejecutar el mismo comando que con 'sudo' para resolver el problema, pero este no es el caso. Sin embargo, corrígeme si me equivoco.

— tommarshall

1

Ejecutar el comando como root debería superar la mayoría de los problemas de permisos, sí. (el lugar probable donde aún fallaría es en un montaje nfs para nombrar uno, un archivo inmutable otro) Un simple chequeo ls -lapara ver por qué el directorio todavía no está vacío. lsattrmostrará archivos inmutables.

— HBruijn

Gracias por la información adicional, sin embargo, lsattruno de los directorios enumerados genera lo siguiente: --------------- ./assets(sin indicador i), y el archivo no está en un montaje nfs. ¿Hay alguna otra razón por la que puedas pensar por qué el comando todavía fallaría con sudo?

— tommarshall

¿Hay algún enlace simbólico allí, o solo archivos reales?

— Marcus Downing