Podczas kopiowania z cprozszerzonymi atrybutami nie są zachowywane, nawet z jawnym

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

lub

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

To samo dotyczy rsync, tj

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

Jednak w docelowym systemie plików mogę ręcznie utworzyć rozszerzony atrybut (za pomocą chattr). Oznacza to, że docelowy system plików obsługuje xattr.

Dlaczego nie mogę zachować xattrprzy pomocy cplub rsync?

Dodatkowe informacje:

• Zarówno źródłowy, jak i docelowy system plików to ext4
• Zarówno źródłowy, jak i docelowy system plików są lokalne (nie NFS)
• Używam Debian Wheezy

Aktualizacja

Po tym, jak trochę się z tym pogubić i przyjrzeć kodowi chattri innym e2fsprogs, jasne jest, że atrybuty ustawione przez chattri ustawione przez libattr(np. Za pomocą polecenia setfattr) są bardzo różne. chattrustawia extflagi systemu plików, które po prostu nie są mapowane na nazwany atrybut lub przestrzeń nazw. Żaden z nich nie pojawiają się z każdym wywołaniu libattr„s listxattr. Prawdopodobnie powinny być odwzorowane na nazwane atrybuty w systemprzestrzeni nazw, jak założono poniżej, ale na razie nie jest to jeszcze zaimplementowane. Również system.posix_acl_accessatrybut, który pomyliłem przy mapowaniu do jednego z tych atrybutów poniżej, nie ma nic wspólnego z extflagami systemu plików, a raczej z listami kontroli dostępu. Powiązanestracekomunikaty pojawiają się dla każdego pliku i znikają, gdy tylko cp --preserve=xattrjest używany.

Wygląda na to, że ustawione atrybuty chattrsą specyficzne dla extsystemów plików i że jedynym sposobem na ich wpływ są e2fsprogsnarzędzia. W rzeczywistości manstrona nie używa dla nich terminu „atrybuty rozszerzone”, a raczej „atrybuty pliku”. „Prawdziwe” rozszerzone atrybuty to pary nazwa / wartość, które mogą być zmieniane przez libattrwiele systemów plików i są zaimplementowane. Są co cpi rsyncwygląd i przeniesione do skopiowanych plików, gdy są podane odpowiednie opcje. Wydaje się jednak, że systemistnieje przestrzeń nazw do mapowania chattratrybutów na nazwy i ostatecznie na równoważne atrybuty w innych systemach plików, ale na razie to nie działa.

Oryginalną odpowiedź pozostawiłem nietkniętą, ponieważ jest tam kilka dobrych informacji, choć w niektórych punktach jest ona całkowicie błędna.

Aktualizacja 2

Powinienem wrócił do tego jeszcze przed teraz, ale jak za tą odpowiedź , chattrpracuje na więcej niż tylko extsystemów plików. Według Wikipedii jest to odpowiednik chflagspolecenia w systemach opartych na BSD.

Napisałem skrypt, aby przetestować ustawienie i odczyt tych atrybutów na kilku systemach plików i uzyskałem następujące wyniki:

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

Zauważ, że wszystkie próby odczytu / ustawienia reiserfsflag plików dały powyższy błąd, mimo że jest wymieniony na Wikipedii jako mający pewną funkcjonalność. Nie testowałem reiser4. Również, gdy cflaga może być ustawiona, ext4nie jest honorowane. Mogą istnieć również opcje strojenia / montowania, które wpływają na te flagi, ale nie mogłem ich znaleźć.

Wydaje się jednak, że obecnie chattrjest to jedyne narzędzie w systemie Linux, które może modyfikować te atrybuty, więc żadne narzędzie kopiujące nie jest w stanie ich zachować.

Oryginalna odpowiedź

rsyncWydaje się, że powodem tego jest to, że nawet nie próbuje. Z -Xsekcji rsyncdokumentacji:

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.

Trudno jest odwzorować litery atrybutów używane przez chattri lsattrna bazowe nazwane atrybuty używane w systemie plików (dla jednego nie ma listy w Internecie). Jednak z moich testów Aatrybut odwzorowuje system.posix_acl_accessatrybut, a ponieważ jest to systemprzestrzeń nazw, rsyncnawet nie spróbuję go skopiować.Pozostałe dwie przestrzenie nazw niewymienione we manfragmencie to trustedi security, aby je ustawić, wymagane są uprawnienia roota ( rsyncbez nich nie można próbować).

Najprawdopodobniej atrybuty, które próbujesz ustawić, mieszczą się w systemprzestrzeni nazw, która rsyncignoruje (i prawdopodobnie mądrze). Albo to, albo musisz być rootem, aby uzyskać te, które nie są.

Jeśli chodzi o cp, wydaje się, że w grze występują błędy.Uruchomiony stracena cp -a, mam następujące dwie ciekawe linie:

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

i

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

Po pierwsze, fgetxattrwywołanie nie zwraca żadnych danych (prawdopodobnie dlatego, że ich nie ma - wystarczy istnienie atrybutu), ale w jakiś sposób cpznajduje 28 bajtów (śmieci?) Danych, aby ustawić je jako wartość atrybutu w pliku docelowym. To wydaje się być błędem cp, ale raczej przyczyną problemu wydaje się być błąd, libattrponieważ fsetattrwywołanie powraca 0do sukcesu bez ustawiania atrybutu.

Zachowuję to ext4niezależnie od tego, czy montuję user_xattr. Nie mogę znaleźć na to żadnej dokumentacji poza stwierdzeniem, że „niektóre systemy” potrzebują tej opcji montowania, aby rozszerzone atrybuty działały. Niby mój (Debian Jessie) nie. Nawet problem z montażem, który przeoczyłem, jest niewłaściwy fsetattri dlatego cpcicho zawodzi.

Faktycznie user_xattrjest potrzebne na ext2, ext3, reiserfsi być może kilku innych. Nie jest to konieczneext4

Należy również zauważyć, że attrnarzędzia setfattr, getfattri attr(ten ostatni jest udokumentowana być tylko dla XFStylko, ale wydaje się działać tak samo dobrze jak inni o ext4) mają problemy w pracy niczego, ale usernazw. Dostaję się, Operation not supportedjeśli spróbuję użyć setfattratrybutu w systemprzestrzeni nazw (lub żadnej przestrzeni nazw w przypadku tego błędu ). setfattrwydaje się odnosić sukcesy w przestrzeniach nazw trustedi security, ale potem getfattrnie może odczytać niczego, a także nie może odczytać niczego z systemprzestrzeni nazw ustawionej przez chattr. Powodem chattrjest to, że używa ioctlpołączenia, a nie libattr.

To, co działa idealnie, to ustawienie rozszerzonych atrybutów w userprzestrzeni nazw za setfattrpomocą i używanie rsynclub cpkopiowanie z nimi nienaruszonymi (nie ma nawet problemów z cptym, że nie podasz wartości podczas tworzenia atrybutu). Myślę, że sedno jest takie, że obecnie używa się systemwartości przestrzeni nazwbuggy i / lubnieobsługiwane, przynajmniej w Debianie i prawdopodobnie także w innych dystrybucjach. Prawdopodobnie rsyncprogramiści to wiedzą i dlatego je ignorują.