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 xattr
con cp
o 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
filesystems
rsync
cp
xattr
Martin Vegter
fuente
fuente
mount
este sistema de archivos?setfattr -n system.name0 -v "value" test_file
. Copiétest_file
to / from ext4 / jfs / xfs concp --preserve=all
y no tuve ningún problema para preservar los atributos extendidos.Respuestas:
Actualizar
Después de jugar un poco más con esto y mirar el código para
chattr
y otrose2fsprogs
, está claro que los atributos establecidos porchattr
y los establecidos porlibattr
( por ejemplo, con el comandosetfattr
) son muy diferentes.chattr
estableceext
indicadores 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 alibattr
'slistxattr
. Probablemente deberían mapearse a atributos con nombre en elsystem
espacio de nombres como se supone a continuación, pero hasta ahora esto no está implementado por completo. Además, elsystem.posix_acl_access
atributo que confundí con la asignación a uno de estos atributos a continuación, no tiene nada que ver con losext
indicadores del sistema de archivos y más bien tiene que ver con las listas de control de acceso. El asociadostrace
los mensajes aparecen para cualquier archivo y desaparecen cuando solocp --preserve=xattr
se usa.Parece que los atributos establecidos por
chattr
son específicos de losext
sistemas de archivos y que la única forma de afectarlos es a través de lase2fsprogs
herramientas. De hecho, laman
pá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 alteradoslibattr
e implementados en múltiples sistemas de archivos. Estos son los quecp
yrsync
look para y transfieren a los archivos copiados cuando se dan las opciones correctas. Sin embargo, parece quesystem
existe un espacio de nombres para asignar loschattr
atributos 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 ,
chattr
funciona en más que soloext
sistemas de archivos. Según Wikipedia , es equivalente alchflags
comando 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:
Tenga en cuenta que todos los intentos de leer / configurar
reiserfs
marcas de archivo dieron el error anterior, a pesar de que se enumera en Wikipedia con alguna funcionalidad. No hice la pruebareiser4
. Además, aunque lac
bandera se puede ponerext4
, 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
chattr
es 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
rsync
parece ser que ni siquiera lo intenta. De la-X
sección de larsync
documentación:Es difícil mapear las letras de atributo utilizadas porLos otros dos espacios de nombres que no se mencionan en elchattr
ylsattr
con 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, elA
atributo se asigna alsystem.posix_acl_access
atributo y, dado que este es elsystem
espacio de nombres,rsync
ni siquiera intentará copiarlo.man
fragmento sontrusted
ysecurity
, se requieren privilegios de root para establecerlos (yrsync
no lo intentarán sin).Lo más probable es que los atributos que ha intentado establecer caigan en el
system
espacio de nombres quersync
ignora (y probablemente sabiamente). O eso o debes ser root para obtener los que no lo son.En cuanto aCorrercp
, parece que hay errores en juego.strace
encp -a
, consigo las siguientes dos líneas interesantes:y
En primer lugar, lafgetxattr
llamada no devuelve ningún dato (probablemente porque no hay ninguno; la existencia del atributo es suficiente), pero de alguna maneracp
encuentra 28 bytes de datos (¿basura?) Para establecer como el valor del atributo en el archivo de destino. Esto parece un errorcp
, pero más bien lo que está causando los problemas parece ser un errorlibattr
ya que lafsetattr
llamada regresa0
para el éxito sin establecer realmente el atributo.Obtengo este comportamiento
ext4
independientemente de si monto conuser_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á malfsetattr
y, por lo tanto,cp
falla en silencio.En realidad
user_xattr
se necesita enext2
,ext3
,reiserfs
y posiblemente algunos otros. No es necesario paraext4
Tenga en cuenta también que las
attr
herramientassetfattr
,getfattr
yattr
(este último se ha documentado que ser sólo paraXFS
solamente, pero parece que funciona tan bien como los otros paraext4
) tienen problemas para trabajar en otra cosa que eluser
espacio de nombres. ObtengoOperation not supported
si intento usarsetfattr
para poner un atributo en elsystem
espacio de nombres (o no hay espacio de nombres según este error ).setfattr
parece tener éxito en los espacios de nombrestrusted
ysecurity
, pero luegogetfattr
no puede leer nada y tampoco puede leer nada delsystem
espacio de nombres establecido porchattr
. La razón quechattr
tiene éxito es que usa unaioctl
llamada y nolibattr
.Sin embargo, lo que funciona perfectamente es establecer atributos extendidos en el
user
espacio de nombressetfattr
y usarlosrsync
ocp
copiarlos intactos (incluso no hay problemascp
si no especifica un valor al crear el atributo). Creo que la conclusión es que usarsystem
valores de espacio de nombres es actualmentebuggy y / osin soporte, al menos en Debian y probablemente otras distribuciones también. Es probable que losrsync
desarrolladores lo sepan, por eso los ignoran.fuente