preservar atributos extendidos con cp / rsync

12

Al copiar con cp, los atributos extendidos no se conservan, incluso con valores explícitos

cp -a --preserve=all /source /dest

o

cp -a --preserve=xattr /source /dest

Lo mismo ocurre con rsync, es decir

rsync -aq -A -X --delete /source /dest

Sin embargo, en el sistema de archivos de destino, puedo crear atributos extendidos manualmente (con chattr). Esto significa que el sistema de archivos de destino es compatible con xattr.

¿Por qué no puedo preservar xattrcon cpo rsync?

Información Adicional:

  • Los sistemas de archivos de origen y destino son ext4
  • Los sistemas de archivos de origen y destino son locales (no nfs)
  • Estoy usando Debian Wheezy
Martin Vegter
fuente
¿Cómo está montando este sistema de archivos de destino? ¿Está sobre NFS?
slm
el sistema de archivos de destino es un sistema de archivos local
Martin Vegter
¿Puedes mostrar la salida de mounteste sistema de archivos?
slm
1
¿En qué variante y versión de Unix? ¿Qué tipo de sistema de archivos en ambos extremos, con qué opciones de montaje?
Gilles 'SO- deja de ser malvado'
1
@MartinVegter ¿Podría dar un atributo de muestra que tenga su archivo? Acabo de crear el sistema de archivos ext4 en dos archivos e hice una prueba con setfattr -n system.name0 -v "value" test_file. Copié test_fileto / from ext4 / jfs / xfs con cp --preserve=ally no tuve ningún problema para preservar los atributos extendidos.
UVV

Respuestas:

14

Actualizar

Después de jugar un poco más con esto y mirar el código para chattry otros e2fsprogs, está claro que los atributos establecidos por chattry los establecidos por libattr( por ejemplo, con el comando setfattr) son muy diferentes. chattrestablece extindicadores del sistema de archivos que simplemente no se asignan a un atributo con nombre o espacio de nombres. Ninguno de ellos aparece con ningún llamado a libattr's listxattr. Probablemente deberían mapearse a atributos con nombre en el systemespacio de nombres como se supone a continuación, pero hasta ahora esto no está implementado por completo. Además, el system.posix_acl_accessatributo que confundí con la asignación a uno de estos atributos a continuación, no tiene nada que ver con los extindicadores del sistema de archivos y más bien tiene que ver con las listas de control de acceso. El asociadostracelos mensajes aparecen para cualquier archivo y desaparecen cuando solo cp --preserve=xattrse usa.

Parece que los atributos establecidos por chattrson específicos de los extsistemas de archivos y que la única forma de afectarlos es a través de las e2fsprogsherramientas. De hecho, la manpágina en realidad no usa el término 'atributos extendidos' para ellos, sino más bien 'atributos de archivo'. Los atributos extendidos 'reales' son pares de nombre / valor que pueden ser alterados libattre implementados en múltiples sistemas de archivos. Estos son los que cpy rsynclook para y transfieren a los archivos copiados cuando se dan las opciones correctas. Sin embargo, parece que systemexiste un espacio de nombres para asignar los chattratributos a los nombres y, en última instancia, a los atributos equivalentes en otros sistemas de archivos, pero por ahora esto no funciona.

He dejado la respuesta original intacta ya que hay buena información allí, aunque en algunos puntos va bastante mal.

Actualización 2

Debería haber regresado a esto nuevamente antes, pero según esta respuesta , chattrfunciona en más que solo extsistemas de archivos. Según Wikipedia , es equivalente al chflagscomando en sistemas basados ​​en BSD.

Escribí un script para probar la configuración y la lectura de estos atributos en algunos sistemas de archivos y obtuve los siguientes resultados:

ext4:
suS-iadAcj-t-e-- mnt/test_file
suSDiadAcj-tTe-- mnt/test_dir

reiserfs:
lsattr: Inappropriate ioctl for device While reading flags on mnt/test_file
lsattr: Inappropriate ioctl for device While reading flags on mnt/test_dir

xfs:
--S-iadA-------- mnt/test_file
--S-iadA-------- mnt/test_dir

btrfs:
--S-iadAc------C mnt/test_file
--SDiadAc------C mnt/test_dir

Tenga en cuenta que todos los intentos de leer / configurar reiserfsmarcas de archivo dieron el error anterior, a pesar de que se enumera en Wikipedia con alguna funcionalidad. No hice la prueba reiser4. Además, aunque la cbandera se puede poner ext4, no se respeta. También puede haber opciones de ajuste / montaje que afectan estos indicadores, pero no pude encontrar ninguno.

Sin embargo, parece que actualmente chattres la única utilidad en Linux capaz de modificar estos atributos y, por lo tanto, ninguna utilidad de copia es capaz de preservarlos.

Respuesta original

La razón rsyncparece ser que ni siquiera lo intenta. De la -Xsección de la rsyncdocumentación:

For systems that support extended-attribute namespaces, a copy being done by a
super-user copies all namespaces except system.*.  A normal user only  copies
the user.* namespace.

Es difícil mapear las letras de atributo utilizadas por chattry lsattrcon los atributos nombrados subyacentes utilizados en el sistema de archivos (por un lado, no hay una lista en Internet). Sin embargo, según mis pruebas, el Aatributo se asigna al system.posix_acl_accessatributo y, dado que este es el systemespacio de nombres, rsyncni siquiera intentará copiarlo.Los otros dos espacios de nombres que no se mencionan en el manfragmento son trustedy security, se requieren privilegios de root para establecerlos (y rsyncno lo intentarán sin).

Lo más probable es que los atributos que ha intentado establecer caigan en el systemespacio de nombres que rsyncignora (y probablemente sabiamente). O eso o debes ser root para obtener los que no lo son.

En cuanto a cp, parece que hay errores en juego.Correr straceen cp -a, consigo las siguientes dos líneas interesantes:

fgetxattr(3, "system.posix_acl_access", 0x7fff5181c0e0, 132) = -1 ENODATA (No data available)

y

fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = 0

En primer lugar, la fgetxattrllamada no devuelve ningún dato (probablemente porque no hay ninguno; la existencia del atributo es suficiente), pero de alguna manera cpencuentra 28 bytes de datos (¿basura?) Para establecer como el valor del atributo en el archivo de destino. Esto parece un error cp, pero más bien lo que está causando los problemas parece ser un error libattrya que la fsetattrllamada regresa 0para el éxito sin establecer realmente el atributo.

Obtengo este comportamiento ext4independientemente de si monto con user_xattr. No puedo encontrar ninguna documentación sobre esto aparte de decir que 'algunos sistemas' necesitan esta opción de montaje para que funcionen los atributos extendidos. Aparentemente el mío (Debian Jessie) no. Incluso hay un problema creciente que me he perdido, está mal fsetattry, por lo tanto, cpfalla en silencio.

En realidad user_xattrse necesita en ext2, ext3, reiserfsy posiblemente algunos otros. No es necesario paraext4

Tenga en cuenta también que las attrherramientas setfattr, getfattry attr(este último se ha documentado que ser sólo para XFSsolamente, pero parece que funciona tan bien como los otros para ext4) tienen problemas para trabajar en otra cosa que el userespacio de nombres. Obtengo Operation not supportedsi intento usar setfattrpara poner un atributo en el systemespacio de nombres (o no hay espacio de nombres según este error ). setfattrparece tener éxito en los espacios de nombres trustedy security, pero luego getfattrno puede leer nada y tampoco puede leer nada del systemespacio de nombres establecido por chattr. La razón que chattrtiene éxito es que usa una ioctlllamada y no libattr.

Sin embargo, lo que funciona perfectamente es establecer atributos extendidos en el userespacio de nombres setfattry usarlos rsynco cpcopiarlos intactos (incluso no hay problemas cpsi no especifica un valor al crear el atributo). Creo que la conclusión es que usar systemvalores de espacio de nombres es actualmentebuggy y / osin soporte, al menos en Debian y probablemente otras distribuciones también. Es probable que los rsyncdesarrolladores lo sepan, por eso los ignoran.

Graeme
fuente