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


Disons que Johnny crée un fichier VIDE. On l'appelle foobar.py. Quand Johnny le permet, il court chmod 755 foobar.py. Le fichier a maintenant les métadonnées de

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

Où sont toutes les métadonnées stockées dans ce fichier? La taille du fichier est 0, alors comment conserve-t-il les métadonnées lorsqu’il est transféré sur un autre lecteur?


26
2017-12-28 06:55


origine


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


Réponses:


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 (même si certains ne peuvent pas être copiés du tout).

En d’autres termes, la plupart des systèmes d’exploitation n’ont pas d’appel «copie de fichier avec métadonnées». Le programme de copie de fichier crée simplement un nouveau fichier nommé foobar.py, copie la totalité des 0 octets de données, puis utilise utime () ou SetFileTime () pour rendre son heure de modification identique à celle de l'original. De même, les autorisations de fichiers seraient "copiées" en les définissant à nouveau à l'aide de chmod () ou en copiant l'attribut POSIX ACL.

Certaines métadonnées ne sont pas copiées. La définition de la propriété requiert des privilèges root, de sorte que 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.

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

$ strace -v cp foo bar
...
open ("foo", O_RDONLY) = 3
open ("bar", O_WRONLY | O_TRUNC) = 4
lire (3, "test \ n", 131072) = 5
write (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 d'origine 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
open ("foo", O_RDONLY | O_NOFOLLOW) = 3
open ("bar", O_WRONLY | O_TRUNC) = 4
lire (3, "test \ n", 131072) = 5
write (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
...

41
2017-12-28 07:15



pour compléter cette réponse, vous devez mentionner: - lors de la copie sur un autre lecteur: les métadonnées sont lues depuis la source et reproduites sur la cible si les paramètres appropriés (ou les options) (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 commencer par faire une archive (.zip, .tar, etc.) des fichiers et d’extraire de cette archive sur la cible, en donnant à nouveau le programme (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)? - cat
Merci de me donner une réponse détaillée à cette question sur laquelle j'ai réfléchi. - juniorRubyist


Il diffère généralement d'un système de fichiers à un autre dans lequel les métadonnées sont stockées. Sur la famille de systèmes de fichiers ext2, les métadonnées que vous avez mentionnées (propriétaire, groupe, autorisations, heure) sont stockées dans le inode. L'inode stocke également (pointage vers) les blocs que le fichier occupe sur le disque. L'inode fait ne pas stocker le nom de fichier.

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

Il existe d'autres types de métadonnées (par ex. Autorisations ACL) qui sont stockés dans des endroits différents.

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 instruisent cp copier également les métadonnées, en lisant les anciennes métadonnées avec stat et modifier les nouvelles métadonnées en conséquence.


11
2017-12-28 09:11





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 autres (parfois aussi le nom du fichier).

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

Dans certains systèmes de fichiers, les entrées de répertoire sont des fichiers comme les autres, mais masquées. FAT et FAT32 sont de tels systèmes de fichiers (le répertoire racine de FAT est "spécial"). Lorsque vous créez un fichier, vous ajoutez / modifiez une entrée dans le fichier qui décrit le dossier dans lequel réside le fichier. Chaque entrée est assez grande pour stocker la taille du fichier, le nom et la date, et rien d'autre (noms longs occupant plusieurs entrées; la taille par défaut de 32 octets peut contenir un seul nom dans l'ancien format de caractères 8 + 3. , en supposant que ma mémoire fonctionne). Le système ext est similaire, mais l'entrée du répertoire est dynamiquement dimensionnée 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 disponible ne change pas du tout; ces octets sont stockés à l'intérieur l'inode. Je pense que la famille ext * le supporte (et NTFS aussi). Cela permet de gérer un grand nombre de très petits fichiers.

Dans d'autres systèmes de fichiers, il existe un système de fichiers "fantôme" le long du système principal, qui stocke ces attributs supplémentaires. Pas seulement informations sur les fichiers, mais éventuellement icônes de fichiers ainsi que.

Certains systèmes ont les deux: NTFS a les métadonnées complètes du répertoire fonctionnant à la manière d’un inode, et la possibilité de créer flux de données alternatifstenant des informations supplémentaires qui ne modifient (apparemment) rien dans le fichier "principal".


4
2017-12-28 13:35



Les noms de fichiers ne sont pas stockés avec le fichier, ils font partie du répertoire inode. C'est pourquoi les liens durs fonctionnent - Sobrique
cette réponse est en conflit avec les dirkt sur le stockage des noms de fichiers, je me demande ce qui est correct - cat
Désolé, j'ai confondu les choses, et @dirkt en a le droit. Correction de la réponse. - LSerni
Ils font partie de la annuaire, mais habituellement ne 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, alors son Contenu serait la liste des fichiers (noms et leurs inodes). - grawity