更新
これをもう少しいじり、chattrandのコードを見てみると、e2fsprogsによって設定された属性chattrとによって設定された属性libattr（例：commandを使用setfattr）は非常に異なっていることが明らかです。ファイルシステムフラグをchattr設定しextますが、これは単に名前付き属性または名前空間にマップしません。いずれもそれらのはへの呼び出しで現れていませんlibattrの listxattr。以下で想定されるように、おそらく名前空間の名前付き属性にマップする必要systemがありますが、現時点では完全に実装されていません。また、system.posix_acl_access以下のこれらの属性の1つへのマッピングと間違えた属性は、extファイルシステムフラグとは関係がなく、むしろアクセス制御リストと関係があります。関連するstraceメッセージはすべてのファイルに対して表示され、cp --preserve=xattr使用されている場合のみ消えます。
によって設定される属性chattrはextファイルシステムに固有であり、それらに影響を与える唯一の方法はe2fsprogsツールを使用することであるようです。実際、manページは実際には「拡張属性」という用語を使用せず、むしろ「ファイル属性」を使用します。「実際の」拡張属性は、名前/値のペアでありlibattr、複数のファイルシステムで変更および実装できます。これらは、正しいオプションが与えられたときに、コピーされたファイルcpをrsync探して転送するものです。ただしsystem、chattr属性を名前にマップし、最終的に他のファイルシステム上の同等の属性にマップするために名前空間が存在するように見えますが、現時点では機能しません。
いくつかの良い情報があるので、元の答えはそのままにしておきましたが、ある点ではかなり間違っています。
更新2
私は今までに再びこれに戻るべきでしたが、この答えによると、chattr単なるextファイルシステム以上のもので動作します。Wikipediaによると、これはchflagsBSDベースのシステムのコマンドと同等です。
いくつかのファイルシステムでこれらの属性の設定と読み取りをテストするスクリプトを作成し、次の結果を得ました。
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
reiserfsいくつかの機能を備えているとしてウィキペディアにリストされているにもかかわらず、ファイルフラグの読み取り/設定を試みると、上記のエラーが発生することに注意してください。私はテストしませんでしたreiser4。また、cフラグを設定するext4ことはできますが、それは尊重されません。これらのフラグに影響するチューニング/マウントオプションもありますが、見つかりませんでした。
ただし、現在のところchattr、これらの属性を変更できるのはLinux上の唯一のユーティリティであるため、コピーユーティリティはこれらを保持できません。
元の回答
その理由は、rsync試してさえいないからだと思われます。ドキュメントの-Xセクションからrsync：
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.
で使用される属性文字にマップすることは困難であるchattrとlsattr、ファイルシステムで使用される基礎となる名前の属性（1のためのインターネット上のリストがない）にします。私のテストからは、A属性は属性にマップされ、system.posix_acl_accessこれはsystem名前空間なので、rsyncコピーしようとさえしません。記載されていない他の2つのネームスペースmanスニペットがあるtrustedとsecurity、root権限は、これらを設定する必要があります（とrsyncせずにしようとはしません）。
ほとんどの場合、設定しようとした属性は、無視する（おそらく賢明な）system名前空間に該当しますrsync。そうでないか、そうでないものを取得するには、rootになる必要があります。
に関してはcp、プレイ中にバグがあるようです。で実行straceするcp -aと、次の2つの興味深い行が表示されます。
fgetxattr(3, "system.posix_acl_access", 0x7fff5181c0e0, 132) = -1 ENODATA (No data available)
そして
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
まず、fgetxattr呼び出しはデータを返さない（おそらく何も存在しないため-属性の存在が十分である）が、何らかの方法でcp28バイトの（ジャンク？）データを見つけて、宛先ファイルに属性値として設定します。これはバグのように思えるcpのではなく、問題を引き起こしているもののバグのようですlibattrとしてfsetattr呼び出しが戻っ0実際に属性を設定せずに成功するため。
でext4マウントするかどうかに関係なく、この動作を取得しuser_xattrます。「一部のシステム」では、拡張属性が機能するためにこのマウントオプションが必要であると言う以外に、これに関するドキュメントは見つかりません。一見私のもの（Debian Jessie）はそうではありません。私が見逃したマウントの問題がありますが、それは間違っているためfsetattr、cp静かに失敗するのです。
実際user_xattrに必要とされext2、ext3、reiserfsそしておそらくいくつかの他。必要ありませんext4
また、attrツールsetfattr、getfattrおよびattr（後者はのみのために文書化さXFSれていますが、のために他と同様に動作するようですext4）user名前空間以外で動作する問題があることに注意してください。名前空間に属性を配置するOperation not supportedために使用しようとした場合に取得setfattrしsystemます（または、このバグのように名前空間なし）。と名前空間でsetfattr成功したように見えますが、その後、何も読み戻せず、で設定された名前空間から何も読み込めません。成功する理由は、呼び出しを使用するのではなく、呼び出しを使用するからです。trustedsecuritygetfattrsystemchattrchattrioctllibattr
ただし、完全に機能するのは、user名前空間に拡張属性を設定し、そのままsetfattr使用するrsyncかcp、そのまま使用してコピーすることです（cp属性の作成時に値を指定しなくても問題はありません）。一番下の行は、system名前空間値の使用が現在バギーおよび/または少なくともDebianやその他のディストリビューションではサポートされていません。rsync開発者はこれを知っている可能性が高いため、それらは無視されます。