Existe-t-il un tar ou un cpio plus intelligent pour récupérer efficacement un fichier stocké dans l'archive?

J'utilise tarpour archiver un groupe de très gros bz2fichiers (multi-Go) .

Si j'utilise tar -tf file.tarpour répertorier les fichiers dans l'archive, cela prend beaucoup de temps (~ 10-15 minutes).

De même, il cpio -t < file.cpiofaut autant de temps pour terminer, plus ou moins quelques secondes.

En conséquence, la récupération d'un fichier à partir d'une archive (via tar -xf file.tar myFileOfInterest.bz2par exemple) est aussi lente.

Existe-t-il une méthode d'archivage qui conserve un "catalogue" facilement accessible avec l'archive, afin qu'un fichier individuel dans l'archive puisse être récupéré rapidement?

Par exemple, une sorte de catalogue qui stocke un pointeur sur un octet particulier dans l'archive, ainsi que la taille du fichier à récupérer (ainsi que toute autre information spécifique au système de fichiers).

Existe-t-il un outil (ou argument vers tarou cpio) qui permet une récupération efficace d'un fichier dans l'archive?

tar (et cpio et afio et pax et des programmes similaires) sont des formats orientés flux - ils sont destinés à être diffusés directement sur une bande ou transférés dans un autre processus. alors qu'en théorie, il serait possible d'ajouter un index à la fin du fichier / flux, je ne connais aucune version qui le fasse (ce serait une amélioration utile cependant)

cela n'aidera pas avec vos archives tar ou cpio existantes, mais il existe un autre outil, dar ("archive de disque"), qui crée des fichiers d'archive qui contiennent un tel index et peut vous donner un accès direct rapide à des fichiers individuels dans l'archive .

si dar n'est pas inclus avec votre unix / linux-dist, vous pouvez le trouver sur:

http://dar.linux.free.fr/

Vous pouvez utiliser SquashFS pour de telles archives. C'est

• conçu pour être accessible à l'aide d'un pilote de fusible (bien qu'il existe une interface traditionnelle)
• compressé (plus la taille du bloc est grande, plus efficace)
• inclus dans le noyau Linux
• stocke les UID / GID et l'heure de création
• sensible à l'endianess, donc assez portable

Le seul inconvénient que je connaisse est qu'il est en lecture seule.

http://squashfs.sourceforge.net/ http://www.tldp.org/HOWTO/SquashFS-HOWTO/whatis.html

Bien qu'il ne stocke pas d'index, il starest censé être plus rapide que tar. De plus, il prend en charge les noms de fichiers plus longs et prend mieux en charge les attributs de fichier.

Comme je suis sûr que vous le savez, la décompression du fichier prend du temps et serait probablement un facteur dans la vitesse d'extraction même s'il y avait un index.

Modifier: vous voudrez peut-être également y jeter un œil xar. Il a un en-tête XML qui contient des informations sur les fichiers dans l'archive.

Depuis la page référencée:

L'en-tête XML de Xar lui permet de contenir des métadonnées arbitraires sur les fichiers contenus dans l'archive. En plus des métadonnées de fichier Unix standard telles que la taille du fichier et ses heures de modification et de création, xar peut stocker des informations telles que les bits de fichier ext2fs et hfs, les drapeaux Unix, les références aux attributs étendus, les informations du Finder Mac OS X, Mac OS Fourches de ressources X et hachage des données de fichier.

Thorbjørn Ravn Anderser a raison. GNU tar crée des archives "recherchables" par défaut. Mais il n'utilise pas ces informations lorsqu'il lit ces archives si l'option -n n'est pas donnée. Avec l'option -n, je viens d'extraire un fichier de 7 Go à partir d'une archive de 300 Go dans le temps nécessaire pour lire / écrire 7 Go. Sans -n, cela a pris plus d'une heure et n'a donné aucun résultat.

Je ne sais pas comment la compression affecte cela. Mon archive n'a pas été compressée. Les archives compressées ne sont pas "recherchables" car le tar GNU actuel (1.26) décharge la compression vers un programme externe.

Le seul format d'archive que je connaisse qui stocke un index est ZIP, car j'ai dû reconstruire les index corrompus plus d'une fois.

Il n'indexe pas à ma connaissance, mais j'utilise le vidage et la restauration avec des fichiers volumineux, et la navigation dans l'arborescence de restauration en mode interactif pour sélectionner des fichiers aléatoires est TRÈS rapide.

Vous pouvez utiliser le format d'archivage / compression 7z (7zip) si vous avez accès au p7zip-fullpackage.

Sur Ubuntu, vous pouvez utiliser cette commande pour l'installer:

$ sudo apt-get install p7zip-full

Pour créer une archive que vous pouvez utiliser 7z a <archive_name> <file_or_directory>et si vous ne voulez pas compresser les fichiers et souhaitez simplement les "stocker" tels quels, vous pouvez utiliser l' -mx0option comme:

$ 7z a -mx0 myarchive.7z myfile.txt

Creating archive myarchive.7z

Vous pouvez ensuite extraire les fichiers en utilisant 7z e:

$ 7z e myarchive.7z

Processing archive: myarchive.7z
Extracting  myfile.txt

Ou vous pouvez lister l'index de l'archive avec le 7z lqui est pratique pour rechercher avec grep:

$ 7z l myarchive.7z | grep

2014-07-08 12:13:39 ....A            0            0  myfile.txt

C'est également la tpossibilité de tester l'intégrité, ud'ajouter / mettre à jour un fichier dans l'archive et dde supprimer un fichier.

REMARQUE IMPORTANTE
N'utilisez pas le format 7zip pour les sauvegardes du système de fichiers Linux car il ne stocke pas le propriétaire et le groupe des fichiers contenus.

Je crois que GNU tar est capable de faire ce que vous voulez, mais je ne trouve pas de ressource définitive le disant.

Dans tous les cas, vous avez besoin d'un format d'archivage avec un index (car cela vous permettra de faire ce que vous voulez). Je ne crois pas que les fichiers ZIP peuvent devenir aussi gros, malheureusement.