Journal cpio c'est mieux que tar

Posté par  (site web personnel) .
Étiquettes :
14
22
juil.
2010
Cher journal,

Cet après-midi, j'ai découvert un fait intéressant : le format d'archive cpio est supérieur au format tar.

tar(5) — tape archive — et cpio(5) — copy in, copy out — sont deux formats d'archive utilisés sous *nix. Ils ne sont pas identiques dans leur format interne, mais servent à la même chose : stocker des fichiers divers — réguliers, répertoires, etc. — avec leurs noms et leurs propriétés — droits, propriétaires, etc. Plusieurs versions de ces formats ont été publiées, pour étendre leurs capacités.

Ces deux formats étant à peu près équivalents dans leur fonctionnalité, ils diffèrent en fait surtout par l'interface standard de l'outil canonique qui sert à les manipuler, respectivement, tar(1) et cpio(1) : tar prend sur sa ligne de commande les options, l'action à effectuer et les fichiers à insérer ou à extraire, alors que cpio prend la liste des fichiers à insérer ou à extraire sur son entrée standard.

L'interface originale de cpio est très utile pour des cas spécifiques où l'on veut faire une sélection préciser des fichiers à archiver, avec un find(1) branché sur cpio. L'interface de tar, plus directe, a gagné la bataille, au point que l'outil cpio de GNU permet de manipuler des tarballs !

Pour mettre une fin à la guerre entre tar et cpio, un outil standard a été spécifié et développé : pax(1) — paix, et portable archive. Il s'agit uniquement d'un outil, et non d'un format. Cet outil permet de manipuler des archives cpio ou des tarballs, et dispose d'un mode à la tar — tout sur la ligne de commande — et d'un mode à la cpio — liste des fichiers en entrée standard.

J'en viens au titre de cet article : cpio, c'est mieux. Pour une raison très simple : tar peut stocker des fichiers réguliers, des répertoires, des liens symboliques, des tubes nommés, des périphériques à blocs et des périphériques au caractère. C'est tout : il manque… les sockets ! Quant à cpio, et bien, lui, au moins, peut stocker tout type de fichier. On peut, de façon sûre, archiver un système de fichier complet en cpio, alors que dans un tarball, les sockets seraient perdues.

Quant à pax, si j'en parle, c'est évidemment parce que l'interface de cpio est beaucoup trop contraignante dans la plupart des cas, et que pax permet donc de créer des archives cpio de façon simple :
pax -zx cpio -wf toto.cpio.gz toto/
  • z gzipper
  • x cpio utiliser le format cpio
  • w write, c'est à dire mode d'écriture d'une archive, autrement dit création
  • f toto.cpio.gz écrire dans toto.cpio.gz plutôt que sur la sortie standard
  • # Correction

    Posté par  (site web personnel) . Évalué à 4.

    le format d'archive cpio est supérieur que format tar

    Je voulais dire : « est supérieur au format tar », évidemment.
    • [^] # Re: Correction

      Posté par  (site web personnel) . Évalué à 5.

      A vue de nez, ça a été corrigé.
      Ça serait bien que les admodos laissent une trace visible de leurs modifications. Y a rien de mal à corriger une erreur, mais c'est mieux de l'indiquer clairement.
      Transparence, toussa…
      • [^] # Re: Correction

        Posté par  (site web personnel) . Évalué à 8.

        Si c'est une vraie modif OK je suis d'accord mais si c'est juste pour corriger une typo je ne vois pas l'intérêt de laisser une trace.
        Tu imagines un journal qui se terminerai par:

        NdM 11h32 : Ajout d'un s final au mot "périphérique".
        NdM 11h42 : Majuscule au début de la phrase "Quant à pax".
        NdM 13h06 : Remplacement de "que format tar" par "au format tar".

        Ce serait ridicule. Et puis les news noyau doubleraient de taille après inclusion de la liste des corrections de fautes ;-)
        • [^] # Re: Correction

          Posté par  . Évalué à 3.

          regarde une changelog d'un article Wikipedia et tu verras que ça n'a rien de ridicule. Il faudrait juste prévoir un lien vers la changelog pour ne pas l'inclure dans l'article.

          Transparence, toussa...
          • [^] # Re: Correction

            Posté par  (site web personnel) . Évalué à 3.

            C'est NoNo qui va être super-content de vous récupérer en contributeurs pour la prochaine version de linuxfr en Rails, ce genre de changement n'étant pas prévu d'être mis en place dans templeet...

            Vous me faites bien rire avec votre transparence, elle est belle la confiance que vous mettez dans vos modérateurs ;-) (et oui, c'est bien moi qui ai effectué la correction de typo et je vous laisse retrouver les autres modifications subrepticement effectuées vu votre choix du terme "transparence" et une allusion douteuse qui me vient à l'esprit en le lisant).
        • [^] # Re: Correction

          Posté par  (site web personnel) . Évalué à 2.

          Au moins
          « NdM : corrections orthographiques/grammaticales. »
          « NdM : correction URL. »
          « NdM : ajout troll religio-politique subliminal. »

          (et j'imagine un journal qui se termineraiT :P)
          • [^] # Re: Correction

            Posté par  . Évalué à 0.

            Dans ce cas, ça ferrait:

            NdM : corrections orthographiques/grammaticales.
            NdM : corrections orthographiques/grammaticales.
            NdM : corrections orthographiques/grammaticales.

            C'est super pratique.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Correction

              Posté par  . Évalué à 10.

              Le fait de mettre un "s" à "corrections" permet de ne l'ecrire qu'une seule fois.

              Oui, c'est super pratique, le pluriel.
              • [^] # Re: Correction

                Posté par  . Évalué à 1.

                Sauf si toutes les fautes ne sont pas corrigées en une seule fois.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Correction

                  Posté par  (site web personnel) . Évalué à 2.

                  Non, ça on s'en fiche du nombre de fois.
                  On veut juste savoir que qq1 est passé corriger à un moment ou un autre.
                  Comme un « last edited by Machin. »
            • [^] # Re: Correction

              Posté par  . Évalué à 1.

              Dans ce cas, ça ferait:

              NdM : correction orthographique/grammaticale.
  • # Sérieusement?

    Posté par  . Évalué à 10.

    Tu penses vraiment que pouvoir sauvegarder des sockets est une killer features du format cpio?
    Déjà si t'arrives à trouver un use-case réaliste ça sera bien.
    • [^] # Re: Sérieusement?

      Posté par  (site web personnel) . Évalué à 6.

      Sauvegarder le système de fichiers complet d'un système d'exploitation. Au hasard, d'un chroot ou d'un conteneur OpenVZ ou VServer.
    • [^] # Re: Sérieusement?

      Posté par  . Évalué à 2.

      Tu penses vraiment que pouvoir sauvegarder des sockets est une killer features du format cpio?
      Déjà si t'arrives à trouver un use-case réaliste ça sera bien.


      A part tous les programmes qui dialoguent par socket avec des droits d'accès spécifiques, ça ne présente pas trop d'intérêt en effet.

      Chez moi ça ne représente que les filtres mails, le greylisting, les proxy et les workers HTTP et les IPC de tout un tas de scripts Bash que j'utilise pour l'administration de mes serveurs en vrrp/carp.
      • [^] # Re: Sérieusement?

        Posté par  . Évalué à 10.

        Et ? Tes programmes ne recréent pas leurs sockets quand ils sont lancés ?
        • [^] # Re: Sérieusement?

          Posté par  . Évalué à 2.

          Je serais déja surpris qu'il existe un programme qui ne le fasse passe pas. quand on fait un bind sur une socket unix, elle est obligatoirement et automatiquement crée. Et quand on fait un connect, il ne peut marcher que si un serveur y a fait un bind/listen... et je voit pas de raison de changer ce mecanisme en vérifiant l'éxistance de la socket a la main.
        • [^] # Re: Sérieusement?

          Posté par  . Évalué à 3.

          Et ? Tes programmes ne recréent pas leurs sockets quand ils sont lancés ?

          Si bien sur, il ne me reste plus qu'à descendre les droits à la main pour que ca marche correctement.
          • [^] # Re: Sérieusement?

            Posté par  . Évalué à 3.

            Le fait de respecter les droits sur les socket unix est une spécificité Linux, qui n'apparaît dans aucune norme. Ça parait logique de se baser la dessus si tu sait que ton programme ne sera pas portable, mais sinon c'est un bug en bonne et due forme, et ta sécurité sautera si tu porte ton programme sur d'autres systèmes.

            Les sockets unix, c'est comme pour tout les sockets, n'importe qui peut se connecter n'importe ou. Le seul avantage des sockets unix par rapport aux socket TCP, c'est qu'on est sur que ce n'est pas écoutable facilement (puisque ça ne sort pas de la machine).
            • [^] # Re: Sérieusement?

              Posté par  . Évalué à 5.

              Le fait de respecter les droits sur les socket unix est une spécificité Linux, qui n'apparaît dans aucune norme.

              Certes, mais ça juste marche sous Linux, FreeBSD, OpenBSD et HP-UX pour ceux que j'ai testé.
              Sous Linux et FreeBSD ca supporte même très bien les ACLs.

              De façon générale, je ne cherche de toute façon pas ici à créer un programme portable, mais à faire une sauvegarde d'un système sur lequel je ne suis pas forcément le seul à travailler. De fait je ne sais pas si il y a quelque part une socket qui utilise les droits d'accès fichiers, et si je peux ne pas le savoir (ie ne pas passer deux heures à comprendre pourquoi la restauration ne passe pas, ou pire avoir des données corrompues silencieusement pendant une ou deux semaines avant que quelqu'un ne découvre le pot aux roses), ca m'arrange.
            • [^] # Re: Sérieusement?

              Posté par  (site web personnel) . Évalué à 2.

              Je ne sais pas si c'est portable ou non, mais :
              1. c'est logique ;
              2. c'est tout l'intérêt des sockets Unix : sans ça, autant faire du réseau local normalement.
              • [^] # Re: Sérieusement?

                Posté par  . Évalué à 2.

                1. Non. (réponse à qualité d'argumentation identique)
                2. Tu peux toujours faire appliquer des droits à tes sockets en les plaçant dans des répertoires sur lequel tu positionne les droits. En plus ça élimine le problème insoluble du post.
    • [^] # Re: Sérieusement?

      Posté par  (site web personnel) . Évalué à 6.

      C'est super lourd quand t'arrive pas à retrouver tes chaussettes
      • [^] # Re: Sérieusement?

        Posté par  . Évalué à 1.

        M'enfin c'est encore une preuve de l'existence de la Licorne Rose Invisible (bénis soient ses sabots sacrés), pour ceux qui en doutaient encore !

        (voilà, dévier le thread en troll religion : c'est fait !)
      • [^] # Re: Sérieusement?

        Posté par  . Évalué à 4.

        "Le barbare gagne un niveau !"
  • # Autres formats

    Posté par  (site web personnel) . Évalué à 4.

    Ceci étant, tar et cpio sont de vieux formats, qui ont été étendus au fur et à mesure sans trop de concertation, un peu à la RACHE®, quoi.

    Il y a plusieurs alternatives à ces formats :
    — zip : format déficient à l'origine — aussi déficient que DOS, quoi —, il est potable dans sa version Info-ZIP, sous *nix ;
    — dar : un format intéressant, avec un outil dont l'interface en ligne de commande est documentée de façon assez confuse ;
    — xar : à ma connaissance le format d'archive le plus moderne, malheureusement mort depuis 2007 alors qu'il pourrait évoluer (compression lzma, par exemple).

    Pour un archivage très basique — pas de répertoires, que des fichiers à plat —, le format ar peut faire l'affaire. Pour des besoins basiques (répertoires, fichiers réguliers sans permission), n'importe quel format, tar, cpio, zip, peut faire l'affaire. Pour des besoins normaux (répertoires, fichiers réguliers, liens symboliques), tar et cpio conviennent. Et pour des besoins avancés, cpio convient, au prix d'inconvénients — pas de mutualisation des liens physiques, par exemple.
    • [^] # Re: Autres formats

      Posté par  . Évalué à 2.

      > xar : à ma connaissance le format d'archive le plus moderne, malheureusement mort depuis 2007 alors qu'il pourrait évoluer (compression lzma, par exemple).

      Je ne connaissais pas, une rapide recherche m'a conduit vers ce site et plus précisément vers cette page : https://code.google.com/p/xar/source/browse/trunk/xar/test/c(...)

      On y voit : echo "Testing normal archival creation/extraction with lzma compression"

      Il y a l'air d'avoir quand même un peu d'activité.

      The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

    • [^] # Re: Autres formats

      Posté par  . Évalué à 5.

      xar : à ma connaissance le format d'archive le plus moderne, malheureusement mort depuis 2007 alors qu'il pourrait évoluer (compression lzma, par exemple).

      J'aime bien dissocier l'archivage de la compression.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Autres formats

        Posté par  (site web personnel) . Évalué à 4.

        Oui, moi aussi, mais ce n'est pas forcément judicieux. On peut avoir intérêt à appliquer une compression différente selon les fichiers, et pouvoir accéder aux informations et aux fichiers de façon indépendante n'est pas un luxe.
      • [^] # Re: Autres formats

        Posté par  (site web personnel) . Évalué à 8.

        J'aime bien dissocier l'archivage de la compression.

        Je ne suis que moyennement d'accord avec l'intérêt de ceci, tout spécialement pour deux cas :
        - afficher la liste des fichiers de l'archive.
        +Dans le cas d'un archivage suivit d'une compression, tu ne peux pas récupérer la liste des fichiers, sans parcours intégral de tout le fichier. Si tu as 20 go d'archive en .tar.gz sur un disque en USB 1.0, cela prendra du temps pour récupérer la liste.
        + Par contre, dans le cas d'un archivage avec compression intégrée (zip, rar, etc....), le soft de décompression peut faire des "sauts" dans l'archive, afin de retrouver la liste des fichiers. Cela limite la quantité de données lues dans le fichier, donc le résultat arrivera plus vite

        - résistance à la corruption :
        + Si tu prends un .tar.gz, et que tu le corromps (écriture aléatoire de données dans le fichier), l'extraction bloquera dès la première erreur trouvée
        + D'autres formats qui lient archivage et compression (arj par exemple) supportent largement mieux la corruption. Les données compressées situées dans la zone corrompu seront certes illisbles. Par contre, les autres, et tout spécialement ceux situés après la zone corrompu, seront extractable. On perdra donc quelque chose, mais pas tout...
  • # :)

    Posté par  . Évalué à 10.

    cpio c'est mieux que tar

    et tar c'est mieux que jamais ?
  • # Emacs, c'est toi ?

    Posté par  (site web personnel) . Évalué à 10.

    >> au point que l'outil cpio de GNU permet de manipuler des tarballs !

    J'espère qu'il ne permet pas de lire ses emails, aller sur IRC, ni ed consulter un psy, sinon, ça sera encore un projet redondant…
    • [^] # Re: Emacs, c'est toi ?

      Posté par  . Évalué à 2.

      ed consulter un psy ? tu veux dire que tu interfaces l'éditeur standard et emacs ?
  • # J’ajoute unp

    Posté par  (site web personnel) . Évalué à 6.

    J’ai découvert unp il y a peu. C’est me semble-t-il un scipt debian (présent aussi dans les dérivés debian). Le but unique : décompresser !
    Donc unp toto.{zip, tar.gz, tar.bz2, tgz, rar, etc.} décompresse l’archive dans le répertoire courant. Normalement lancer unp sans rien donne la liste des formats supportés, mais ça ne fonctionne pas chez moi !
    J’entends déjà (si, si) les sirène du « c’est mieux de connaître chaque outil ». Certes. Mais moi je me contente d’avoir besoin de décompresser un fichier et pour mon usage unp est parfait.
    Quoi qu’il en soit, ça fait partie de mes indispensables de la console (avec autojump, bien entendu, puisqu’on vous dit qu’il faut utiliser autojump !)
    • [^] # Re: J’ajoute unp

      Posté par  . Évalué à -10.

      T'as raison, c'est TELLEMENT DUR de retenir que un .tar.gz c'est tar xvzf et un .tar.bz2 c'est tar xvjf OULALA.

      Puis fais gaffe hein, ensuite t'as un .zip, là c'est unzip tout court. Mais j'admets, c'est peut-être trop d'un coup là.
      • [^] # Re: J’ajoute unp

        Posté par  . Évalué à 9.

        Attention, derrière toi ! Un .7z !

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: J’ajoute unp

        Posté par  (site web personnel) . Évalué à 10.

        Avec les dernières versions de GNU tar, tar xf décompresse tout seul le bzip2, le lzma, le gzip et le xz. Pas besoin de rajouter z, j ou autre.
      • [^] # Re: J’ajoute unp

        Posté par  . Évalué à 4.

        Un tar, quel que soit la compression, c'est tar xf fichier. Enfin, sauf pour ceux qui ont la nostalgie des UNIX de l'époque SCO, mais je pense qu'on a davantage de GNUistes ici.
        • [^] # Re: J’ajoute unp

          Posté par  . Évalué à 2.

          Avec bzip2 et gzip oui mais il le fait aussi avec lzma ? (J'utilise pas lzma pour ça que j'ai jamais essayé)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: J’ajoute unp

          Posté par  . Évalué à 2.

          C'est vrai aussi pour BSD ?
    • [^] # Re: J’ajoute unp

      Posté par  . Évalué à 2.

      Y'a aussi "atool", par exemple "atool -x archive.zip" et hop.

      Et en plus (et surtout), atools évite les Tarbomb.

      J'ai une fonction shell qui va bien :


      ax () {
      if [ $# -eq 0 ]
      then
      echo 'Gimme a file to unpack !'
      return
      fi
      if [ ! -x /usr/bin/atool ]
      then
      echo 'Need "atool"'
      return
      fi
      if [ ! -x /bin/mktemp ]
      then
      echo 'Need "mktemp"'
      return
      fi
      TMP=`mktemp /tmp/aunpack.XXXXXXXXXX`
      atool -x --save-outdir=$TMP "$@"
      DIR="`cat $TMP`"
      [ "$DIR" != "" -a -d "$DIR" ] && cd "$DIR"
      rm -i -rf $TMP
      }


      Et du coup, "ax toto.tgz" extrait toto.tgz et me place dans le répertoire créé.

      (oui, c'est de la flemme)
      • [^] # Re: J’ajoute unp

        Posté par  (site web personnel) . Évalué à 2.

        Il y a plus simple !

        aunpack monfichier.tar.gz

        Et ça évite les tarbomb tout seul....

        Et c'est inclus avec atool !

        Et il y a aussi apack ;-)
        • [^] # Re: J’ajoute unp

          Posté par  . Évalué à 1.

          Voui, mais.

          aunpack est simplement un alias de "atool -x", mais la fonction magique (qui est donnée dans le man de atool) permet de se déplacer dans le répertoire créé (si un répertoire est créé).
  • # A la base

    Posté par  (site web personnel) . Évalué à 4.

    Il me semble que tar à la base a été créé principalement pour piloter les librairies bandes type dat, lto et non pour gérer la compression/décompression et tout le bazar.

    Son rôle était d'envoyer les fichiers sur la bande de la façon qui va bien.

    Born to Kill EndUser !

    • [^] # Re: A la base

      Posté par  . Évalué à 0.

      Toi tu as lu ce que signifié tar. Par contre je vois pas l'intérêt d'envoyer la fnac, Gibert etc.. sur bande magnétique (si tu veut parler de bibliothèque nous sommes d'accord).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: A la base

      Posté par  (site web personnel) . Évalué à 3.

      Il faut aussi voir que tar n'est pas une bonne idée pour faire de la sauvegarde système...

      En effet, ce dernier note d'abord la taille du fichier à écrire puis le fichier, si la taille de ce dernier à changer entre temps, on risque de se retrouver avec des erreurs de redondance cyclique...

      A noté que j'ai pas vu ce genre d'erreur depuis un moment sous Linux, GNUtar corrige peut être le probleme.
  • # Re: cpio c'est mieux que tar

    Posté par  . Évalué à 1.

    Mieux vaut tar que jamais.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.