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