Bonsoir,
j’aimerais savoir dans une perspective de backup où sont sauvegardées les données des fichiers (qui est le proprio, quels sont les droits etc…)
Je sais que lorsqu’on copie les fichiers sur certains systèmes de fichiers on perd ces métadonnées.
Est ce qu’en compressant un répertoire on conserverait ces données là?
Dans un système de fichiers de type Unix (POSIX) comme ext4, les méta-données d’un fichier sont stockées dans une structure appelée inode.
Les systèmes de fichiers non Unix n’ont pas forcément d’équivalent. Par exemple dans les systèmes de fichiers FAT, il n’y a pas d’inodes et les méta-données d’un fichier sont stockées directement dans l’entrée de répertoire.
Qu’entends-tu par "compresser un répertoire ?
PH t’as répondu pour les auter points mais pour celui là :
Le plus simple est que tu fasse un essai et tu verra bien 
je voulais dire faire un tar.gz d’un répertoire.
:’( apprendre par l’essais c’est ce qu’il y a de plus long, mais bon maintenant que c’est dit je vais essayer
C’est aussi ce qu’il y a de plus efficace car tu es acteur de ton aprentissage, pas simple consomateur de la connaissance des autres
c’est joliment dit. Perso on me l’a souvent répété vu que je fais du dev, et c’est horrible parce que des fois on a besoin d’apprendre pas de tester.
Quand on perd 1h a faire des tests là où un résumé ou un petit cours nous aurait permis de tout comprendre en moins de 10 minutes c’est pas productif.
Surtout qu’un test n’a pas toujours valeur de loi, parfois pour comprendre un comportement d’un programme, langage c’est des dizaines de tests qu’il faut faire.
Être acteur de son apprentissage c’est dans la manière de digérer l’information. une écoute peut être active ou passive.
Bref c’était une digression ^^ je ne marchande pas lol
As-ton avis pourquoi les prof font copier autant les élèves …
C’est sur que écouter un bon sachant c’est déjà pas mal et on perd pas trop de temps, mais point de vue rétention d’info si tu pratique pas derrière dans les jours qui suivent tu as oublié 75% des infos.
Donc ou avoir un cours théorique avant c’est bien, mais avoir un peu de pratique derrière c’est (bien) mieux.
voir
tar peut préserver les droits et les propriétaires, ce n’est pas le cas de zip.
En cas de changement de machine cela peut nécessiter de regarder de plus près les options de tar.
Tu veux donc dire dans une archive tar. La compression n’est qu’accessoire, réalisée sur le fichier contenant l’archive et non les fichiers contenus dans l’archive.
C’est curieux cette tendance généralisée à confondre archive et compression. J’ai même lu plusieurs fois “décompresser une image ISO” alors qu’une image ISO n’est ni une archive ni compressée.
Oui, une archive tar peut préserver les permissions et propriétaires. La remarque de @jweber est pertinente : les utilisateurs et groupes peuvent être identifiés de deux façons : par leur nom ou par leur identifiant numérique (UID pour les utilisateurs et GID pour les groupes). Or la correspondance entre les noms et les UID/GID est propre à chaque système (sauf si tous les systèmes utilisent une même base d’utilisateurs centralisée). Un nom d’utilisateur n’a pas forcément le même UID sur les systèmes source et destination de l’archive, et réciproquement un même UID ne correspond pas forcément au même utilisateur. tar a une option --numeric-owner pour enregistrer les propriétaires dans l’archive par leur UID/GID au lieu de leur nom.
La seule pratique peut aussi conduire à faire des généralisations abusives à partir de son cas particulier et de sa seule expérience. Je l’ai souvent observé. "J’ai toujours vu faire comme ça, donc j’en déduis que c’est la seule façon de faire."
Exemple concret : toutes les machines UEFI fournies avec Windows sont partitionnées au format GPT, donc on en déduit abusivement que UEFI et GPT sont indissociablement liés. Mais c’est faux : c’est un cas particulier propre à Windows.
Pour préciser un peu
Dans un système de fichiers Linux/Unix à chaque fichier correspond un inode (voir wikipedia, par exemple) unique. Les inodes sont une vision “kernel” des fichiers (listes chainées de pointeurs vers des blocs d’un disque), l’utilisateur lambda voit plutôt les structures arborescentes répertoires/fichiers/liens/etc. Comme précisé plus haut les droits et aspects de propriétés sont inscrits dans les inodes. ces droits sont liés à un utilisateur sur un système donné. Ils ne sont pas inscrits dans les fichiers eux-mêmes.
Si on fait une copie (mv, cp, …) on crée une nouvelle structure d’inodes, avec les droits du créateur de la copie (voir umasq). Les inodes ne sont évidemment pas copiés sauf dans une copie physique d’un disque, au niveau des blocs.
Le logiciel tar rajoute au contenu compressé d’un fichier la partie pertinente de l’inode (voir https://fr.wikipedia.org/wiki/Tar_(informatique)#Format_du_fichier ) pour permettre la reconstruction des droits et quelques autres informations. Évidemment si on change de système il y a quelques contraintes !
C’est fort, car l’archive compressée par tar peut être conservée sur un support qui ne connait pas ces droits (disque ntfs ou autre), tout est dans l’archive.
Cette affaire de droits se complique évidemment quand on considère des ressources partagées en réseau. C’est un autre sujet !! Un exemple simple que tout un chacun peut expérimenter : si sur ma machine je déclare un répertoire comme partagé sur un réseau windows, via samba, sans me préoccuper des droits, un fichier (ou répertoire) créé par mon voisin d’une autre machine appartient à “nobody”, ce qui est évidemment vexant pour moi. Mon seul droit est de recopier la chose pour retrouver mes droits, ou de changer le proprio via sudo.
Tout ceci peut évidemment être paramétré plus correctement, mais cela relève de la configuration de samba, pas des systèmes de fichiers de la machine source ou de la machine destination (chercher docs sur samba et les droits réseau).
Autre variante pour traiter les droits de façon plus fine : les ACL (access control list). Mais attention, j’ai vu dans les temps anciens un administrateur réseau remplir les disques durs (petits à l’époque) avec les ACLs dans un système en réseau d’enseignement, donc avec des centaines d’utilisateurs de milliers de fichiers.
Je ne suis pas d’accord avec cette façon de présenter les choses. Certes l’allocation des blocs à un inode est la cuisine interne du noyau, mais des métadonnées comme le type (fichier, répertoire, socket, périphérique, lien symbolique…), la taille, l’utilisateur et le groupe propriétaires, les permissions… sont visibles par l’utilisateur et affectent directement l’utilisation du fichier. Quant à l’arborescence des répertoires, elle est utilisée autant par le noyau pour faire la correspondance entre un fichier et son inode que par l’utilisateur.
Attention : mv ne crée une copie et donc un nouvel inode que si le fichier est déplacé dans un autre système de fichiers. Si le fichier est juste renommé ou déplacé dans le même système de fichiers, l’inode est conservé et c’est seulement l’arborescence des répertoires qui est modifiée.
D’autre part, des options de cp permettent d’appliquer les permissions du fichier source à la copie, dans la mesure du possible (il peut être nécessaire d’être root).
Hep ! Je répète que tar ne compresse pas. C’est un programme de compression distinct comme gzip, bzip2 ou xz qui est invoqué pour compresser ou décompresser l’archive tar à la volée.
Rien à dire, aucune objection à ces remarques. J’avais sans doute rédigé un peu vite.
Ca explique la double extention .tar.gz, mais je ne comprends pas :
si on compresse une archive et que cette archive contient des fichier alors ils sont aussi compressé non?
Indirectement. Ils ne sont pas compressés individuellement.