preservare gli attributi estesi con cp / rsync


12

Durante la copia cp, gli attributi estesi non vengono conservati, anche con esplicito

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

o

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

Lo stesso vale per rsync, cioè

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

Tuttavia, sul filesystem di destinazione, posso creare manualmente l'attributo esteso (con chattr). Ciò significa che il filesystem di destinazione supporta xattr.

Perché non riesco a conservare xattrcon cpo rsync?

Informazioni aggiuntive:

  • Sia i filesystem di origine che quelli di destinazione sono ext4
  • Sia i filesystem di origine che quelli di destinazione sono locali (non nfs)
  • Sto usando Debian Wheezy

Come stai montando questo filesystem di destinazione? È su NFS?
slm

il filesystem di destinazione è un filesystem locale
Martin Vegter

Puoi mostrare l'output di mountper questo filesystem?
slm

1
Su quale variante e versione di Unix? Quali tipi di filesystem su entrambe le estremità, con quali opzioni di mount?
Gilles 'SO-smetti di essere malvagio' il

1
@MartinVegter Potresti dare un esempio di attributo del tuo file? Ho appena creato il filesystem ext4 in due file e ho fatto un test setfattr -n system.name0 -v "value" test_file. Ho copiato test_filein / da ext4 / jfs / xfs con cp --preserve=alle non ho avuto problemi a preservare gli attributi estesi.
UVV

Risposte:


14

Aggiornare

Dopo aver fatto un po 'di confusione con questo ancora e guardando il codice per chattre altro e2fsprogs, è chiaro che gli attributi impostati da chattre quelli impostati da libattr(ad esempio con il comando setfattr) sono molto diversi. chattrimposta extflag di filesystem che semplicemente non si associano a un attributo o spazio dei nomi con nome. Nessuno di loro presentarsi con qualsiasi chiamata a libattr's listxattr. Probabilmente dovrebbero essere associati ad attributi nominati nello systemspazio dei nomi come ipotizzato di seguito, ma al momento questo è completamente non implementato. Anche l' system.posix_acl_accessattributo che ho scambiato per il mapping a uno di questi attributi di seguito, non ha nulla a che fare con i extflag del filesystem ed è piuttosto a che fare con le liste di controllo degli accessi. Associatostracei messaggi vengono visualizzati per qualsiasi file e scompaiono quando cp --preserve=xattrviene utilizzato solo .

Sembra che gli attributi impostati chattrsiano specifici per i extfilesystem e che l'unico modo per influenzarli sia attraverso gli e2fsprogsstrumenti. In effetti la manpagina non utilizza effettivamente il termine "attributi estesi" per loro, ma piuttosto "attributi di file". Gli attributi estesi "reali" sono coppie nome / valore che possono essere modificate libattre implementate su più filesystem. Si tratta di ciò cpe rsynccercare e trasferire verso i file copiati quando sono date le giuste opzioni. Sembra tuttavia che systemesista uno spazio dei nomi per mappare gli chattrattributi sui nomi e, in definitiva, su attributi equivalenti su altri filesystem, ma per ora non funziona.

Ho lasciato intatta la risposta originale in quanto ci sono alcune buone informazioni lì, anche se in alcuni punti va abbastanza male.

Aggiornamento 2

Avrei dovuto tornare di nuovo a questo prima d'ora, ma secondo questa risposta , chattrfunziona più di un semplice extfilesystem. Secondo Wikipedia , è equivalente al chflagscomando sui sistemi basati su BSD.

Ho scritto uno script per testare l'impostazione e la lettura di questi attributi su alcuni filesystem e ho ottenuto i seguenti risultati:

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

Si noti che tutti i tentativi di leggere / impostare reiserfsflag di file hanno dato l'errore sopra riportato, nonostante sia elencato su Wikipedia come dotato di alcune funzionalità. Non ho provato reiser4. Anche mentre la cbandiera può essere posizionata, ext4non viene onorata. Potrebbero esserci anche opzioni di ottimizzazione / montaggio che influenzano questi flag, ma non sono riuscito a trovarne.

Sembra tuttavia che attualmente chattrsia l'unica utility su Linux in grado di modificare questi attributi e quindi nessuna utility di copia è in grado di preservarli.

Risposta originale

Il motivo rsyncsembra essere che non è nemmeno provare. Dalla -Xsezione della rsyncdocumentazione:

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.

È difficile mappare le lettere degli attributi utilizzate da chattre lsattragli attributi nominali sottostanti utilizzati nel filesystem (per uno non esiste un elenco su Internet). Dai miei test, l' Aattributo è mappato system.posix_acl_accessall'attributo e poiché questo è lo systemspazio dei nomi, rsyncnon proverà nemmeno a copiarlo.Gli altri due spazi dei nomi non menzionati nello mansnippet sono trustede security, sono necessari i privilegi di root per impostarli (e rsyncnon ci proveranno senza).

Molto probabilmente gli attributi che hai cercato di impostare rientrano nello systemspazio dei nomi che rsyncignora (e probabilmente saggiamente). O quello o devi essere root per ottenere quelli che non lo sono.

Per quanto riguarda cp, sembra che ci siano bug in gioco.Correre stracesu cp -a, ottengo le seguenti due righe interessanti:

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

e

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

Innanzitutto la fgetxattrchiamata non restituisce alcun dato (probabilmente perché non ce n'è - l'esistenza dell'attributo è sufficiente), ma in qualche modo cptrova 28 byte di dati (spazzatura?) Da impostare come valore dell'attributo nel file di destinazione. Sembra un bug in cp, ma piuttosto ciò che sta causando i problemi sembra essere un bug in libattrquanto la fsetattrchiamata ritorna 0per successo senza effettivamente impostare l'attributo.

Ottengo questo comportamento ext4indipendentemente dal fatto che io monti con user_xattr. Non riesco a trovare alcuna documentazione su questo se non per dire che "alcuni sistemi" necessitano di questa opzione di montaggio per il funzionamento degli attributi estesi. Apparentemente mio (Debian Jessie) no. Anche se c'è un problema di montaggio che mi è sfuggito, è sbagliato fsetattre quindi cpfallire silenziosamente.

In realtà user_xattrè necessario su ext2, ext3, reiserfse forse alcuni altri. Non è necessario perext4

Si noti inoltre che gli attrstrumenti setfattr, getfattre attr(quest'ultimo è documentato per essere solo per XFSsolo, ma sembra funzionare altrettanto bene come gli altri per ext4) hanno problemi a lavorare nel nulla, ma il usernamespace. Ottengo Operation not supportedse provo a utilizzare setfattrper inserire un attributo nello systemspazio dei nomi (o nessuno spazio dei nomi come per questo bug ). setfattrsembra riuscire negli spazi dei nomi trustede security, ma poi getfattrnon riesce a leggere nulla indietro e non riesce a leggere nulla dallo systemspazio dei nomi impostato da chattr. La ragione per cui ha chattrsuccesso è che utilizza una ioctlchiamata e non libattr.

Ciò che funziona perfettamente, tuttavia, è l'impostazione degli attributi estesi nello userspazio dei nomi setfattre l'utilizzo rsynco la cpcopia con essi intatti (non ci sono problemi anche cpse non si specifica un valore durante la creazione dell'attributo). Penso che la linea di fondo sia che l'utilizzo systemdei valori dello spazio dei nomi è attualmentebuggy e / onon supportato, almeno in Debian e probabilmente anche in altre distro. Probabilmente gli rsyncsviluppatori lo sanno, motivo per cui li ignorano.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.