Non è memorizzato in quell'archivio. È memorizzato nel filesystem e tutti i parametri vengono copiati manualmente uno per uno (sebbene alcuni non possano essere copiati affatto).
Cioè, la maggior parte dei sistemi operativi non ha realmente una chiamata "copia file con metadati". Il programma di copia file crea semplicemente un nuovo file chiamato foobar.py , copia l'intero 0 byte di dati, quindi utilizza utime() o SetFileTime() per rendere l'ora di modifica uguale a quella dell'originale. Allo stesso modo, i permessi dei file verrebbero "copiati" impostandoli di nuovo usando chmod() o copiando l'attributo POSIX ACL.
Alcuni metadati non vengono copiati. L'impostazione della proprietà richiede i privilegi di root, quindi le copie dei file di qualcun altro appartengono a te e occupano il tuo quota disco. Il ctime (tempo di modifica dell'attributo) è impossibile da impostare manualmente su Unix; btime (ora di nascita/creazione) di solito non viene copiato.
Confronta cp -a foo bar (che copia i metadati) e cp foo bar (che non funziona):
$ strace -v cp foo bar
…
open("foo", O_RDONLY) = 3
open("bar", O_WRONLY|O_TRUNC) = 4
read(3, "test\n", 131072) = 5
write(4, "test\n", 5) = 5
read(3, "", 131072) = 0
close(4) = 0
close(3) = 0
…
$ strace -v cp -a foo bar
…
-- original metadata is retrieved
lstat("foo", {st_dev=makedev(254, 0), st_ino=60569468, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=8,
st_size=5, st_atime=2016-12-28T09:16:59+0200.879714332,
st_mtime=2016-12-28T09:16:55+0200.816363098,
st_ctime=2016-12-28T09:16:55+0200.816363098}) = 0
-- data is copied
open("foo", O_RDONLY|O_NOFOLLOW) = 3
open("bar", O_WRONLY|O_TRUNC) = 4
read(3, "test\n", 131072) = 5
write(4, "test\n", 5) = 5
read(3, "", 131072) = 0
-- modifiction time is copied
utimensat(4, NULL, [{tv_sec=1482909419, tv_nsec=879714332},
{tv_sec=1482909415, tv_nsec=816363098}], 0) = 0
-- ownership is copied (only with 'sudo [strace] cp')
fchown(4, 1000, 1000) = 0
-- extended attributes are copied (xdg.origin.url is set by browsers, wget)
flistxattr(3, NULL, 0) = 0
flistxattr(3, "user.xdg.origin.url\0", 20) = 20
fgetxattr(3, "user.xdg.origin.url", "https://superuser.com/", 22) = 22
fsetxattr(4, "user.xdg.origin.url", "https://superuser.com/", 22, 0) = 0
-- POSIX ACLs are not present, so a basic ACL is built from st_mode
-- (in this case, a simple fchmod() would work as well)
fgetxattr(3, "system.posix_acl_access", 0x7ffc87a50be0, 132) = -1 ENODATA (No data available)
fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = 0
close(4) = 0
close(3) = 0
…
Generalmente differisce da filesystem a filesystem in cui sono archiviati i metadati. Sulla famiglia di filesystem ext2, i metadati che hai menzionato (proprietario, gruppo, autorizzazioni, ora) sono archiviati nell'inode. L'inode memorizza anche (puntatori a) i blocchi che il file occupa su disco. L'inode non memorizza il nome del file.
Puoi accedere a questi dati con il stat chiamata di sistema (man 2 stat ) e usa stat tool per stamparlo (man stat ). Una descrizione dettagliata dei campi inode può essere trovata in linux/include/linux/fs.h nel sorgente del kernel.
Esistono altri tipi di metadati (ad es. autorizzazioni ACL) che vengono archiviati in luoghi diversi.
I metadati non vengono copiati per impostazione predefinita quando si copia il file. Viene invece creato un nuovo file con valori di metadati predefiniti. Ci sono varie opzioni per cp (-p , --preserve ) che istruisce cp per copiare anche i metadati, leggendo i vecchi metadati con stat e modificando di conseguenza i nuovi metadati.
A seconda del file system, le aree sono riservate (semi)staticamente o dinamicamente per contenere metadati come permessi, dimensioni e altro (a volte anche il nome del file).
In Unix, i metadati sono memorizzati nell'inode controllando l'area dati in cui risiede il file (mentre i nomi dei file e i relativi numeri di inode sono memorizzati in una voce di directory).
In alcuni filesystem le voci di directory sono file come qualsiasi altro, ma nascoste alla vista. FAT e FAT32 sono tali filesystem (la directory principale di FAT è "speciale" però). Quando crei un file, aggiungi/modifichi una voce nel file che descrive la cartella in cui risiede il file. Ogni voce è abbastanza grande da memorizzare la dimensione del file, il nome e la data e nient'altro (nomi lunghi che occupano più voci; la dimensione predefinita della voce di 32 byte può contenere un singolo nome nel vecchio formato di 8+3 caratteri. Tutto questo, ovviamente , supponendo che la mia memoria funzioni). Il sistema Ext è simile, ma la voce della directory è dimensionata dinamicamente e contiene solo il nome e il puntatore inode; tutte le altre informazioni sono nell'inode. In questo modo, due voci possono puntare allo stesso file, utile per gestire i file duplicati.
In alcuni filesystem, gli inode possono essere abbastanza grandi da contenere una piccola quantità di dati oltre ai metadati, in modo che se il file può stare lì, non occupa ulteriore spazio su disco. Si crea un file di 45 byte e lo spazio libero su disco non cambia affatto; quei byte sono memorizzati all'interno l'inode. Penso che la famiglia ext* lo supporti (e anche NTFS). Questo aiuta a gestire un gran numero di file molto piccoli.
In altri file system ancora, c'è quello che equivale a un file system "fantasma" lungo quello principale, che memorizza questi attributi extra. Non solo informazioni sui file ma possibilmente anche icone dei file.
Alcuni sistemi hanno entrambi:NTFS ha i metadati della directory completa che funzionano in modo simile a un inode e la possibilità di creare stream di dati alternativi contenente ulteriori informazioni che (apparentemente) non cambiano nulla nel file "principale".