Où vont les métadonnées lorsque vous enregistrez un fichier?

Supposons que Johnny crée un fichier VIDE. Il est appelé foobar.py. Lorsque Johnny autorise son exécution, il s'exécute chmod 755 foobar.py. Le fichier contient désormais les métadonnées de

-rw-r--r-- 1 johnny staff    0 Dec 27 22:53 foobar.py

Où sont stockées toutes ces métadonnées dans ce fichier? La taille du fichier est 0, alors comment conserve-t-il les métadonnées lors de leur transfert vers un autre lecteur?

Il n'est pas stocké dans ce fichier. Il est stocké dans le système de fichiers et tous les paramètres sont copiés manuellement un par un (bien que certains ne puissent pas être copiés du tout).

Autrement dit, la plupart des systèmes d'exploitation n'ont pas vraiment d'appel "copier le fichier avec les métadonnées". Le programme de copie de fichiers crée simplement un nouveau fichier nommé foobar.py, copie l'intégralité des 0 octets de données, puis utilise utime () ou SetFileTime () pour que son heure de modification soit identique à celle de l'original. De même, les autorisations de fichier seraient "copiées" en les redéfinissant à l'aide de chmod () ou en copiant l'attribut ACL POSIX.

Certaines métadonnées ne sont pas copiées. La définition de la propriété nécessite des privilèges root, donc les copies des fichiers de quelqu'un d'autre vous appartiennent et occupent votre quota de disque. Le ctime (temps de changement d'attribut) est impossible à définir manuellement sur Unixes; btime (heure de naissance / création) n'est généralement pas copié non plus.

Comparez cp -a foo bar(qui copie les métadonnées) et cp foo bar(qui ne le fait pas):

$ strace -v cp foo bar
…
ouvert ("foo", O_RDONLY) = 3
ouvert ("bar", O_WRONLY | O_TRUNC) = 4
lire (3, "test \ n", 131072) = 5
écriture (4, "test \ n", 5) = 5
lire (3, "", 131072) = 0
fermer (4) = 0
fermer (3) = 0
…

$ strace -v cp -a foo bar
…
 - les métadonnées originales sont récupérées
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
 - les données sont copiées
ouvert ("foo", O_RDONLY | O_NOFOLLOW) = 3
ouvert ("bar", O_WRONLY | O_TRUNC) = 4
lire (3, "test \ n", 131072) = 5
écriture (4, "test \ n", 5) = 5
lire (3, "", 131072) = 0
 - le temps de modification est copié
utimensat (4, NULL, [{tv_sec = 1482909419, tv_nsec = 879714332},
                    {tv_sec = 1482909415, tv_nsec = 816363098}], 0) = 0
 - la propriété est copiée (uniquement avec 'sudo [strace] cp')
fchown (4, 1000, 1000) = 0
 - les attributs étendus sont copiés (xdg.origin.url est défini par les navigateurs, 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
 - Les ACL POSIX ne sont pas présentes, donc une ACL de base est construite à partir de st_mode
 - (dans ce cas, un simple fchmod () fonctionnerait aussi)
fgetxattr (3, "system.posix_acl_access", 0x7ffc87a50be0, 132) = -1 ENODATA (Aucune donnée disponible)
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
fermer (4) = 0
fermer (3) = 0
…

Il diffère généralement du système de fichiers au système de fichiers où les métadonnées sont stockées. Sur la famille ext2 de systèmes de fichiers, les métadonnées que vous avez mentionnées (propriétaire, groupe, autorisations, heure) sont stockées dans l' inode . L'inode stocke également (pointe vers) les blocs que le fichier occupe sur le disque. L'inode ne stocke pas le nom de fichier.

Vous pouvez accéder à ces données avec l' statappel système ( man 2 stat) et utiliser l' statoutil pour l'imprimer ( man stat). Une description détaillée des champs inode peut être trouvée linux/include/linux/fs.hdans la source du noyau.

Il existe d'autres types de métadonnées (par exemple les autorisations ACL ) qui sont stockées à différents endroits.

Les métadonnées ne sont pas copiées par défaut lorsque vous copiez le fichier. Au lieu de cela, un nouveau fichier avec des valeurs de métadonnées par défaut est créé. Il existe différentes options pour cp( -p, --preserve) qui demandent cpde copier également les métadonnées, en lisant les anciennes métadonnées avec statet en modifiant les nouvelles métadonnées en conséquence.

Selon le système de fichiers, les zones sont réservées (semi-) statiquement ou dynamiquement pour contenir des métadonnées telles que les autorisations, la taille et d'autres (parfois le nom du fichier aussi).

Sous Unix, les métadonnées sont stockées dans l' inode contrôlant la zone de données où réside le fichier ( tandis que les noms de fichier et les numéros d'inode associés sont stockés dans une entrée de répertoire ).

Dans certains répertoires de systèmes de fichiers, les entrées sont des fichiers comme les autres, mais cachées à la vue. FAT et FAT32 sont de tels systèmes de fichiers (le répertoire racine de FAT est "spécial" cependant). Lorsque vous créez un fichier, vous ajoutez / modifiez une entrée dans le fichier qui décrit le dossier dans lequel se trouve le fichier. Chaque entrée est suffisamment grande pour stocker la taille du fichier, le nom et la date, et rien d'autre (les noms longs occupant plusieurs entrées; la taille d'entrée par défaut de 32 octets peut contenir un seul nom dans l'ancien format de 8 + 3 caractères. Tout cela, bien sûr , en supposant que ma mémoire fonctionne). Le système ext est similaire, mais l'entrée de répertoire est de taille dynamique et ne contient que le nom et le pointeur d'inode; toutes les autres informations sont dans l'inode. De cette façon, deux entrées peuvent pointer vers le même fichier, ce qui est utile pour gérer les fichiers en double.

Dans certains systèmes de fichiers, les inodes peuvent être suffisamment volumineux pour contenir une petite quantité de données en plus des métadonnées, de sorte que si le fichier peut y tenir, il n'occupe pas d'espace disque supplémentaire. Vous créez un fichier de 45 octets et l'espace disque libre ne change pas du tout; ces octets sont stockés à l' intérieur de l'inode. Je pense que la famille ext * prend en charge cela (et NTFS aussi). Cela permet de gérer un grand nombre de très petits fichiers.

Dans encore d'autres systèmes de fichiers, il y a ce qui équivaut à un système de fichiers "fantôme" le long du système principal, qui stocke ces attributs supplémentaires. Non seulement des informations sur les fichiers, mais également des icônes de fichiers .

Certains systèmes ont les deux: NTFS a les métadonnées de répertoires complètes fonctionnant de manière inode, et la possibilité de créer des flux de données alternatifs contenant des informations supplémentaires qui ne changent (apparemment) rien dans le fichier "principal".