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

28

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?

juniorRubyist
la source
1
Je ne suis pas un expert mais je suppose que la réponse générale est que lorsque vous avez un disque dur et que vous faites 1+ partitions, vous formatez la partition avec un système de fichiers, par exemple, Windows a tendance à utiliser ntfs et linux peut utiliser ex2, puis le la majeure partie de cette partition est destinée au contenu des fichiers, mais une petite partie est réservée à d'autres éléments, y compris les métadonnées.
barlop
@barlop est essentiellement correct. Les deux systèmes utilisent de l'espace pour enregistrer où les fichiers sont stockés; dans NTFS, la "table de fichiers maîtres" stocke les métadonnées, dans ext2 + c'est dans "inodes".
pjc50
@ pjc50 merci. et les métadonnées à part, quel est le nom de la chose qui est en dehors des partitions? Je suppose que cela dépend si le truc est MBR ou GPT .. Dans MBR le truc s'appelle le MBR .. Comment ça s'appelle en GPT? (Je comprends que GPT a un MBR hérité mais a-t-il sa propre chose aussi, en dehors de toutes les partitions?)
barlop
Connexes: (essentiellement la même chose, mais la question concerne spécifiquement Windows) Comment les métadonnées du fichier sont-elles stockées dans Windows?
gronostaj
2
"chmod 755 ... Le fichier a maintenant les métadonnées de ... -rw-r - r-- ..." vous voulez dire -rwxr-xr-x.
JoL

Réponses:

42

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
…
grawity
la source
3
pour compléter cette réponse, vous devez mentionner: - lors de la copie sur un autre lecteur: les métadonnées sont lues à partir de la source et reproduites sur la cible si les paramètres (ou options) appropriés (par exemple: conserver la date, conserver les droits ou même conserver " tout ") ont été utilisés (comme vous l'avez mentionné). 2) Une alternative est de faire d'abord une archive (.zip, .tar, etc.) des fichiers, et d'extraire de cette archive sur la cible, en donnant à nouveau au programme un endroit (au format archive) pour trouver les métadonnées, et des options / paramètres spécifiques permettent de conserver (ou non) ces métadonnées.
Olivier Dulac
Au deuxième paragraphe: qu'en est-il de stat (2)?
chat
Merci de m'avoir donné une réponse détaillée à cette seule question sur laquelle j'ai réfléchi.
juniorRubyist
11

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.

dirkt
la source
4

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".

LSerni
la source
2
Les noms de fichiers ne sont pas stockés avec le fichier, ils font partie de l'inode du répertoire. C'est pourquoi les liens durs fonctionnent
Sobrique
cette réponse est en conflit avec dirkt sur l'endroit où les noms de fichiers sont stockés, je me demande laquelle est correcte
cat
Désolé, j'ai mélangé les choses et @dirkt en a le droit . Correction de la réponse.
LSerni
Ils font partie du répertoire , mais ne font généralement pas partie de l'inode du répertoire. Il est spécifique à FS, mais si vous considérez un répertoire comme un fichier spécial, son contenu serait la liste des fichiers (noms et leurs inodes).
grawity