Mise à jour
Après avoir joué un peu plus avec cela et en regardant le code de chattr
et d'autres e2fsprogs
, il est clair que les attributs définis par chattr
et ceux définis par libattr
( par exemple avec la commande setfattr
) sont très différents. chattr
définit des ext
indicateurs de système de fichiers qui ne correspondent tout simplement pas à un attribut nommé ou à un espace de noms. Aucun d'entre eux se présentent avec un appel à libattr
l » listxattr
. Ils devraient probablement être mappés aux attributs nommés dans l' system
espace de noms comme supposé ci-dessous, mais pour l'instant cela n'est pas du tout implémenté. De plus, l' system.posix_acl_access
attribut que j'ai confondu avec le mappage vers l'un de ces attributs ci-dessous, n'a rien à voir avec les ext
drapeaux du système de fichiers et concerne plutôt les listes de contrôle d'accès. L'associéstrace
les messages apparaissent pour n'importe quel fichier et disparaissent lorsque seul cp --preserve=xattr
est utilisé.
Il semble que les attributs définis par chattr
sont spécifiques aux ext
systèmes de fichiers et que la seule façon de les affecter est d'utiliser des e2fsprogs
outils. En fait, la man
page n'utilise pas réellement le terme «attributs étendus» pour eux, mais plutôt «attributs de fichier». Les attributs étendus «réels» sont des paires nom / valeur qui peuvent être modifiées par libattr
et sont implémentées sur plusieurs systèmes de fichiers. Ce sont ce que cp
et rsync
regarder et transférer vers les fichiers copiés lorsque les options sont données. Il semble cependant que l' system
espace de noms existe pour mapper les chattr
attributs aux noms et finalement aux attributs équivalents sur d'autres systèmes de fichiers, mais pour l'instant cela ne fonctionne pas.
J'ai laissé la réponse originale intacte car il y a de bonnes informations là-bas, même si elles vont assez loin à certains points.
Update 2
J'aurais dû y revenir encore une fois avant maintenant, mais selon cette réponse , chattr
fonctionne sur plus que des ext
systèmes de fichiers. Selon Wikipedia , elle équivaut à la chflags
commande sur les systèmes basés sur BSD.
J'ai écrit un script pour tester le réglage et la lecture de ces attributs sur quelques systèmes de fichiers et j'ai obtenu les résultats suivants:
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
Notez que toutes les tentatives de lecture / définition d' reiserfs
indicateurs de fichier ont donné l'erreur ci-dessus, même si elle est répertoriée sur Wikipedia comme ayant certaines fonctionnalités. Je n'ai pas testé reiser4
. Même si le c
drapeau peut être activé, ext4
il n'est pas honoré. Il peut également y avoir des options de réglage / montage qui affectent ces indicateurs, mais je n'en ai pas trouvé.
Il semble cependant qu'actuellement, chattr
c'est le seul utilitaire sous Linux capable de modifier ces attributs et donc aucun utilitaire de copie n'est capable de les conserver.
Réponse originale
La raison rsync
semble être que ce n'est même pas essayer. Dans la -X
section de la rsync
documentation:
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.
Il est difficile de mapper les lettres d'attribut utilisées par chattr
et lsattr
avec les attributs nommés sous-jacents utilisés dans le système de fichiers (pour l'un, il n'y a pas de liste sur Internet). D'après mes tests, l' A
attribut est mappé à l' system.posix_acl_access
attribut et comme il s'agit de l' system
espace de noms, rsync
je n'essaierai même pas de le copier.Les deux autres espaces de noms non mentionnés dans l' man
extrait de code sont trusted
et security
, les privilèges root sont nécessaires pour les définir (et rsync
n'essaieront pas sans).
Très probablement, les attributs que vous avez essayé de définir tombent dans l' system
espace de noms qui rsync
ignore (et probablement à bon escient). Soit cela, soit vous devez être root pour obtenir ceux qui ne le sont pas.
Quant à cp
, il semble y avoir des bogues en jeu.En cours strace
d' exécution cp -a
, j'obtiens les deux lignes intéressantes suivantes:
fgetxattr(3, "system.posix_acl_access", 0x7fff5181c0e0, 132) = -1 ENODATA (No data available)
et
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
Tout d'abord, l' fgetxattr
appel ne renvoie aucune donnée (probablement parce qu'il n'y en a pas - l'existence de l'attribut suffit), mais cp
trouve en quelque sorte 28 octets de données (indésirables?) À définir comme valeur d'attribut dans le fichier de destination. Cela semble être un bogue cp
, mais la cause du problème semble être un bogue, libattr
car l' fsetattr
appel revient 0
pour réussir sans réellement définir l'attribut.
J'obtiens ce comportement ext4
indépendamment du fait que je monte avec user_xattr
. Je ne trouve aucune documentation à ce sujet autre que de dire que «certains systèmes» ont besoin de cette option de montage pour que les attributs étendus fonctionnent. Apparemment, le mien (Debian Jessie) ne le fait pas. Même s'il y a un problème de montage que j'ai manqué, il est incorrect fsetattr
et donc cp
à échouer en silence.
En fait , user_xattr
est nécessaire sur ext2
, ext3
, reiserfs
et peut - être quelques autres. Il n'est pas nécessaireext4
Notez également que les attr
outils setfattr
, getfattr
et attr
(celui - ci est documenté pour être seulement pour XFS
que, mais semble fonctionner aussi bien que les autres pour ext4
) ont des problèmes de travail dans quoi que ce soit , mais l' user
espace de noms. J'obtiens Operation not supported
si j'essaye d'utiliser setfattr
pour mettre un attribut dans l' system
espace de noms (ou aucun espace de noms selon ce bogue ). setfattr
semble réussir dans les espaces de noms trusted
et security
, mais getfattr
échoue ensuite à lire quoi que ce soit et ne parvient pas non plus à lire quoi que ce soit à partir de l' system
espace de noms défini par chattr
. La raison qui chattr
réussit est qu'il utilise un ioctl
appel et non libattr
.
Cependant, ce qui fonctionne parfaitement, c'est de définir des attributs étendus dans l' user
espace de noms avec setfattr
et d'utiliser rsync
ou cp
de copier avec eux intacts (il n'y a même aucun problème avec cp
si vous ne spécifiez pas de valeur lors de la création de l'attribut). Je pense que l'essentiel est que l'utilisation de system
valeurs d'espace de noms est actuellementbuggy et / ounon pris en charge, au moins dans Debian et probablement d'autres distributions aussi. Les rsync
développeurs le savent probablement , c'est pourquoi ils les ignorent.