Apres avoir ete insatisfait de GNU tar,
J'ai essayé cpio et recemment pax.
Celui qui ne semble m'avoir posé aucun probleme avec la taille des
fichiers est cpio. Cela dit, il m'a semblé lire que cpio utilisait (par
defaut) un format non libre. Le cahier des charge impose la liberté de ce
format. Bon de toutes facon je devais aussi tester pax avant de decider.
Et c'est la que j'en suis.
root-fctmp>>>> pax --version
pax (pax) 3.0
J'ai un repertoire "toto" qui contient environ 3Go de fchiers et sous
repertoires.
La commande decrite par le man pour archiver est:
root-fctmp>>>> pax -w -f toto.pax ./toto
Le probleme c'est qu'au bout d'un moment (je pense a quand ca atteint 2Go)
il me demande le nom de la deuxieme archive.
Pour contourner le probleme, Stephane Chazelas m'avait indiqué une astuce
assez subtile (d'apres moi) qui consistait a faire ecrire pax sur stdout
(ce qui l'affranchirait de calculer une taille de fichier) et de recuperer
stdout dans un fichier.
root-fctmp>>>> pax -w ./toto > toto.pax
J'obtiens donc un gros fichier de 3.0G d'apres 'du -h'
Je le bzip, puis le transfere chez moi.
5 heures apres...
je decompresse puis, ca passe (Ok, pas de corruption manifestement).
je tente le desarchivage:
root-fctmp>>>> pax -r < toto.pax
pax: Failed stat on <STDIN> <Value too large for defined data type>
ATTENTION! pax archive volume change required.
Ready for archive volume: 1
Input archive name or "." to quit pax.
Archive name >
C'est en fait une erreur parceque je n'ai qu'une seule archive.
Et puis meme si je lui donne le nom de l'archive, il dit que ce n'est pas
valable.
Bon le souci c'est que je dois donc refaire l'archive, en la splittant, et
la retelecharger (re 5 heures) si je ne trouve pas un moyen de
desarchiver cette chose...
Vous avez des pistes?
Et puis j'utilise un outil d'archivage moi pour
avoir un seul gros fichier, et je trouve dommage qu'il m'oblige a le
splitter. Pour mon usage des outil d'archivage, je trouve ca dommage...
--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SauronDeMordor
Bonjour
Apres avoir ete insatisfait de GNU tar, J'ai essayé cpio et recemment pax.
Celui qui ne semble m'avoir posé aucun probleme avec la taille des fichiers est cpio. Cela dit, il m'a semblé lire que cpio utilisait (p ar defaut) un format non libre. Le cahier des charge impose la liberté d e ce format. Bon de toutes facon je devais aussi tester pax avant de decider . Et c'est la que j'en suis.
as tu essaye star ?
perso je ne suis pas fan, je prefere utiliser les commandes dump des file s systemes qui permetent une sauvegarde et restauration des acl a coup sur.
root-fctmp>>>> pax --version pax (pax) 3.0
J'ai un repertoire "toto" qui contient environ 3Go de fchiers et sous repertoires. La commande decrite par le man pour archiver est:
root-fctmp>>>> pax -w -f toto.pax ./toto
Le probleme c'est qu'au bout d'un moment (je pense a quand ca atteint 2 Go) il me demande le nom de la deuxieme archive.
Pour contourner le probleme, Stephane Chazelas m'avait indiqué une as tuce assez subtile (d'apres moi) qui consistait a faire ecrire pax sur stdou t (ce qui l'affranchirait de calculer une taille de fichier) et de recupe rer stdout dans un fichier.
root-fctmp>>>> pax -w ./toto > toto.pax
J'obtiens donc un gros fichier de 3.0G d'apres 'du -h' Je le bzip, puis le transfere chez moi.
5 heures apres...
je decompresse puis, ca passe (Ok, pas de corruption manifestement). je tente le desarchivage:
root-fctmp>>>> pax -r < toto.pax pax: Failed stat on <STDIN> <Value too large for defined data type>
ATTENTION! pax archive volume change required. Ready for archive volume: 1 Input archive name or "." to quit pax. Archive name >
C'est en fait une erreur parceque je n'ai qu'une seule archive. Et puis meme si je lui donne le nom de l'archive, il dit que ce n'est p as valable.
Bon le souci c'est que je dois donc refaire l'archive, en la splittant, et la retelecharger (re 5 heures) si je ne trouve pas un moyen de desarchiver cette chose...
Vous avez des pistes?
Et puis j'utilise un outil d'archivage moi pour avoir un seul gros fichier, et je trouve dommage qu'il m'oblige a le splitter. Pour mon usage des outil d'archivage, je trouve ca dommage...
Bonjour
Apres avoir ete insatisfait de GNU tar,
J'ai essayé cpio et recemment pax.
Celui qui ne semble m'avoir posé aucun probleme avec la taille des
fichiers est cpio. Cela dit, il m'a semblé lire que cpio utilisait (p ar
defaut) un format non libre. Le cahier des charge impose la liberté d e ce
format. Bon de toutes facon je devais aussi tester pax avant de decider .
Et c'est la que j'en suis.
as tu essaye star ?
perso je ne suis pas fan, je prefere utiliser les commandes dump des file s
systemes qui permetent une sauvegarde et restauration des acl a coup sur.
root-fctmp>>>> pax --version
pax (pax) 3.0
J'ai un repertoire "toto" qui contient environ 3Go de fchiers et sous
repertoires.
La commande decrite par le man pour archiver est:
root-fctmp>>>> pax -w -f toto.pax ./toto
Le probleme c'est qu'au bout d'un moment (je pense a quand ca atteint 2 Go)
il me demande le nom de la deuxieme archive.
Pour contourner le probleme, Stephane Chazelas m'avait indiqué une as tuce
assez subtile (d'apres moi) qui consistait a faire ecrire pax sur stdou t
(ce qui l'affranchirait de calculer une taille de fichier) et de recupe rer
stdout dans un fichier.
root-fctmp>>>> pax -w ./toto > toto.pax
J'obtiens donc un gros fichier de 3.0G d'apres 'du -h'
Je le bzip, puis le transfere chez moi.
5 heures apres...
je decompresse puis, ca passe (Ok, pas de corruption manifestement).
je tente le desarchivage:
root-fctmp>>>> pax -r < toto.pax
pax: Failed stat on <STDIN> <Value too large for defined data type>
ATTENTION! pax archive volume change required.
Ready for archive volume: 1
Input archive name or "." to quit pax.
Archive name >
C'est en fait une erreur parceque je n'ai qu'une seule archive.
Et puis meme si je lui donne le nom de l'archive, il dit que ce n'est p as
valable.
Bon le souci c'est que je dois donc refaire l'archive, en la splittant, et
la retelecharger (re 5 heures) si je ne trouve pas un moyen de
desarchiver cette chose...
Vous avez des pistes?
Et puis j'utilise un outil d'archivage moi pour
avoir un seul gros fichier, et je trouve dommage qu'il m'oblige a le
splitter. Pour mon usage des outil d'archivage, je trouve ca dommage...
Apres avoir ete insatisfait de GNU tar, J'ai essayé cpio et recemment pax.
Celui qui ne semble m'avoir posé aucun probleme avec la taille des fichiers est cpio. Cela dit, il m'a semblé lire que cpio utilisait (p ar defaut) un format non libre. Le cahier des charge impose la liberté d e ce format. Bon de toutes facon je devais aussi tester pax avant de decider . Et c'est la que j'en suis.
as tu essaye star ?
perso je ne suis pas fan, je prefere utiliser les commandes dump des file s systemes qui permetent une sauvegarde et restauration des acl a coup sur.
root-fctmp>>>> pax --version pax (pax) 3.0
J'ai un repertoire "toto" qui contient environ 3Go de fchiers et sous repertoires. La commande decrite par le man pour archiver est:
root-fctmp>>>> pax -w -f toto.pax ./toto
Le probleme c'est qu'au bout d'un moment (je pense a quand ca atteint 2 Go) il me demande le nom de la deuxieme archive.
Pour contourner le probleme, Stephane Chazelas m'avait indiqué une as tuce assez subtile (d'apres moi) qui consistait a faire ecrire pax sur stdou t (ce qui l'affranchirait de calculer une taille de fichier) et de recupe rer stdout dans un fichier.
root-fctmp>>>> pax -w ./toto > toto.pax
J'obtiens donc un gros fichier de 3.0G d'apres 'du -h' Je le bzip, puis le transfere chez moi.
5 heures apres...
je decompresse puis, ca passe (Ok, pas de corruption manifestement). je tente le desarchivage:
root-fctmp>>>> pax -r < toto.pax pax: Failed stat on <STDIN> <Value too large for defined data type>
ATTENTION! pax archive volume change required. Ready for archive volume: 1 Input archive name or "." to quit pax. Archive name >
C'est en fait une erreur parceque je n'ai qu'une seule archive. Et puis meme si je lui donne le nom de l'archive, il dit que ce n'est p as valable.
Bon le souci c'est que je dois donc refaire l'archive, en la splittant, et la retelecharger (re 5 heures) si je ne trouve pas un moyen de desarchiver cette chose...
Vous avez des pistes?
Et puis j'utilise un outil d'archivage moi pour avoir un seul gros fichier, et je trouve dommage qu'il m'oblige a le splitter. Pour mon usage des outil d'archivage, je trouve ca dommage...
Rakotomandimby (R12y) Mihamina
( Thu, 19 May 2005 13:34:44 +0200 ) SauronDeMordor :
as tu essaye star ?
Non pas encore. Je me tate encore avec pax.
perso je ne suis pas fan, je prefere utiliser les commandes dump des files systemes qui permetent une sauvegarde et restauration des acl a coup sur.
Le but n'était pas une sauvegarde pour ce coup ci, mais d'agréger tout plein de trucs à transferer en un seul gros fichier. Le but ensuite, serait de l'utiliser avec un 'find' pour pouvoir selectionner les trucs a mettre ensemble...
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Thu, 19 May 2005 13:34:44 +0200 ) SauronDeMordor :
as tu essaye star ?
Non pas encore. Je me tate encore avec pax.
perso je ne suis pas fan, je prefere utiliser les commandes dump des files
systemes qui permetent une sauvegarde et restauration des acl a coup sur.
Le but n'était pas une sauvegarde pour ce coup ci, mais d'agréger tout
plein de trucs à transferer en un seul gros fichier. Le but ensuite,
serait de l'utiliser avec un 'find' pour pouvoir selectionner les trucs a
mettre ensemble...
--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Thu, 19 May 2005 13:34:44 +0200 ) SauronDeMordor :
as tu essaye star ?
Non pas encore. Je me tate encore avec pax.
perso je ne suis pas fan, je prefere utiliser les commandes dump des files systemes qui permetent une sauvegarde et restauration des acl a coup sur.
Le but n'était pas une sauvegarde pour ce coup ci, mais d'agréger tout plein de trucs à transferer en un seul gros fichier. Le but ensuite, serait de l'utiliser avec un 'find' pour pouvoir selectionner les trucs a mettre ensemble...
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
Fred
( Thu, 19 May 2005 13:34:44 +0200 ) SauronDeMordor :
as tu essaye star ?
Non pas encore. Je me tate encore avec pax.
perso je ne suis pas fan, je prefere utiliser les commandes dump des files systemes qui permetent une sauvegarde et restauration des acl a coup sur.
Le but n'était pas une sauvegarde pour ce coup ci, mais d'agréger tout plein de trucs à transferer en un seul gros fichier. Le but ensuite, serait de l'utiliser avec un 'find' pour pouvoir selectionner les trucs a mettre ensemble...
Le problème ne provient-il pas du système de fichiers lui-même ? Sur les Unix un peu anciens, la taille du fichier est stockée dans l'i-node sur un entier long (max 2Go), donc il peut y avoir une incohérence entre cette taille et le total des blocs effectivement utilisés.
Fred
( Thu, 19 May 2005 13:34:44 +0200 ) SauronDeMordor :
as tu essaye star ?
Non pas encore. Je me tate encore avec pax.
perso je ne suis pas fan, je prefere utiliser les commandes dump des files
systemes qui permetent une sauvegarde et restauration des acl a coup sur.
Le but n'était pas une sauvegarde pour ce coup ci, mais d'agréger tout
plein de trucs à transferer en un seul gros fichier. Le but ensuite,
serait de l'utiliser avec un 'find' pour pouvoir selectionner les trucs a
mettre ensemble...
Le problème ne provient-il pas du système de fichiers lui-même ? Sur les
Unix un peu anciens, la taille du fichier est stockée dans l'i-node sur
un entier long (max 2Go), donc il peut y avoir une incohérence entre
cette taille et le total des blocs effectivement utilisés.
( Thu, 19 May 2005 13:34:44 +0200 ) SauronDeMordor :
as tu essaye star ?
Non pas encore. Je me tate encore avec pax.
perso je ne suis pas fan, je prefere utiliser les commandes dump des files systemes qui permetent une sauvegarde et restauration des acl a coup sur.
Le but n'était pas une sauvegarde pour ce coup ci, mais d'agréger tout plein de trucs à transferer en un seul gros fichier. Le but ensuite, serait de l'utiliser avec un 'find' pour pouvoir selectionner les trucs a mettre ensemble...
Le problème ne provient-il pas du système de fichiers lui-même ? Sur les Unix un peu anciens, la taille du fichier est stockée dans l'i-node sur un entier long (max 2Go), donc il peut y avoir une incohérence entre cette taille et le total des blocs effectivement utilisés.
Fred
Damien Wyart
* "Rakotomandimby (R12y) Mihamina" in fr.comp.os.unix:
Apres avoir ete insatisfait de GNU tar, J'ai essayé cpio et recemment pax.
Je ne réponds pas à ta question, mais peux-tu préciser en quoi GNU tar ne te satisfait pas ?
Simple curiosité...
Merci d'avance,
-- DW
* "Rakotomandimby (R12y) Mihamina" <mihamina.rakotomandimby@etu.univ-orleans.fr>
in fr.comp.os.unix:
Apres avoir ete insatisfait de GNU tar,
J'ai essayé cpio et recemment pax.
Je ne réponds pas à ta question, mais peux-tu préciser en quoi GNU tar
ne te satisfait pas ?
Je ne réponds pas à ta question, mais peux-tu préciser en quoi GNU tar ne te satisfait pas ?
Sur ma Debian Sarge, je ne sais encore pourquoi, j'avais un problème de taille de fichier. Le truc c'est que ça date (4 - 5 mois), que je ne me souviens pas de l'erreur exacte, mais que je tentais un "tar + compression à la volée" (tar cjf le_repertoire). Quasiment le même problème que celui-ci.
Je reviendrai probablement vers tar, mais comme on dit, on ne perd rien à essayer au ssi ce qui se fait à coté... :-)
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
Je ne réponds pas à ta question, mais peux-tu préciser en quoi GNU tar
ne te satisfait pas ?
Sur ma Debian Sarge, je ne sais encore pourquoi, j'avais un problème de
taille de fichier. Le truc c'est que ça date (4 - 5 mois), que je ne me
souviens pas de l'erreur exacte, mais que je tentais un "tar + compression
à la volée" (tar cjf le_repertoire). Quasiment le même problème que
celui-ci.
Je reviendrai probablement vers tar, mais comme on dit, on ne perd rien à
essayer au ssi ce qui se fait à coté... :-)
--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Je ne réponds pas à ta question, mais peux-tu préciser en quoi GNU tar ne te satisfait pas ?
Sur ma Debian Sarge, je ne sais encore pourquoi, j'avais un problème de taille de fichier. Le truc c'est que ça date (4 - 5 mois), que je ne me souviens pas de l'erreur exacte, mais que je tentais un "tar + compression à la volée" (tar cjf le_repertoire). Quasiment le même problème que celui-ci.
Je reviendrai probablement vers tar, mais comme on dit, on ne perd rien à essayer au ssi ce qui se fait à coté... :-)
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
TiChou
Dans le message <news:, *Rakotomandimby (R12y) Mihamina* tapota sur f.c.o.unix :
Bonjour
Salut, :)
Apres avoir ete insatisfait de GNU tar, J'ai essayé cpio et recemment pax.
*star* *star* *star*
Comme tu l'auras compris et contrairement à SauronDeMordor (:p) je suis fan de *star*.
-- TiChou
Dans le message <news:pan.2005.05.19.07.56.09.697933@etu.univ-orleans.fr>,
*Rakotomandimby (R12y) Mihamina* tapota sur f.c.o.unix :
Bonjour
Salut, :)
Apres avoir ete insatisfait de GNU tar,
J'ai essayé cpio et recemment pax.
*star* *star* *star*
Comme tu l'auras compris et contrairement à SauronDeMordor (:p) je suis fan
de *star*.
Dans le message <news:, *Rakotomandimby (R12y) Mihamina* tapota sur f.c.o.unix :
Bonjour
Salut, :)
Apres avoir ete insatisfait de GNU tar, J'ai essayé cpio et recemment pax.
*star* *star* *star*
Comme tu l'auras compris et contrairement à SauronDeMordor (:p) je suis fan de *star*.
-- TiChou
Bob qui Trolle
Rakotomandimby (R12y) Mihamina wrote:
Je reviendrai probablement vers tar, mais comme on dit, on ne perd rien à essayer au ssi ce qui se fait à coté... :-)
Au minimum, on perd l'expérience de la communauté des utilisateurs du "vieux" logiciel qu'on échange contre les promesses d'un "neuf", tout en ayant éventuellement le désagréable sentiment de ne pas avoir compris pourquoi ces derniers ne voulaient pas "mieux".
Je regrette parfois de ne pas voir plus de questions comme : "Dites-donc, les croûtons, je ne comprends pas comment vous avez pu survivre sans la feature X du nouveau gschmoll-2.5-12ac-1. Pourquoi vous restez avec votre vieux slkzx(1) du temps où GNU n'existait même pas, hein, dites ?".
suivi proposé sur : fr.misc.bavardages.dinosaures
Rakotomandimby (R12y) Mihamina wrote:
Je reviendrai probablement vers tar, mais comme on dit, on ne perd rien à
essayer au ssi ce qui se fait à coté... :-)
Au minimum, on perd l'expérience de la communauté des utilisateurs du
"vieux" logiciel qu'on échange contre les promesses d'un "neuf", tout en
ayant éventuellement le désagréable sentiment de ne pas avoir compris
pourquoi ces derniers ne voulaient pas "mieux".
Je regrette parfois de ne pas voir plus de questions comme :
"Dites-donc, les croûtons, je ne comprends pas comment vous avez pu
survivre sans la feature X du nouveau gschmoll-2.5-12ac-1. Pourquoi vous
restez avec votre vieux slkzx(1) du temps où GNU n'existait même pas,
hein, dites ?".
Je reviendrai probablement vers tar, mais comme on dit, on ne perd rien à essayer au ssi ce qui se fait à coté... :-)
Au minimum, on perd l'expérience de la communauté des utilisateurs du "vieux" logiciel qu'on échange contre les promesses d'un "neuf", tout en ayant éventuellement le désagréable sentiment de ne pas avoir compris pourquoi ces derniers ne voulaient pas "mieux".
Je regrette parfois de ne pas voir plus de questions comme : "Dites-donc, les croûtons, je ne comprends pas comment vous avez pu survivre sans la feature X du nouveau gschmoll-2.5-12ac-1. Pourquoi vous restez avec votre vieux slkzx(1) du temps où GNU n'existait même pas, hein, dites ?".
suivi proposé sur : fr.misc.bavardages.dinosaures
Emmanuel Florac
Le Thu, 19 May 2005 14:27:30 +0200, Rakotomandimby (R12y) Mihamina a écrit :
Sur ma Debian Sarge, je ne sais encore pourquoi, j'avais un problème de taille de fichier.
Bizarre, normalement il n'y a plus ce genre de problème depuis de longues années...
-- Si non confectus non reficiat.
Le Thu, 19 May 2005 14:27:30 +0200, Rakotomandimby (R12y) Mihamina a
écrit :
Sur ma Debian Sarge, je ne sais encore pourquoi, j'avais un problème de
taille de fichier.
Bizarre, normalement il n'y a plus ce genre de problème depuis de longues
années...
Le Thu, 19 May 2005 14:27:30 +0200, Rakotomandimby (R12y) Mihamina a écrit :
Sur ma Debian Sarge, je ne sais encore pourquoi, j'avais un problème de taille de fichier.
Bizarre, normalement il n'y a plus ce genre de problème depuis de longues années...
-- Si non confectus non reficiat.
Jérémy JUST
On Thu, 19 May 2005 14:27:30 +0200 "Rakotomandimby (R12y) Mihamina" wrote:
Sur ma Debian Sarge, je ne sais encore pourquoi, j'avais un problème de taille de fichier. Le truc c'est que ça date (4 - 5 mois), que je ne me souviens pas de l'erreur exacte, mais que je tentais un "tar + compression à la volée" (tar cjf le_repertoire). Quasiment le même problème que celui-ci.
Et tu as essayé quasiment la même solution, en utilisant des pipes pour que les programmes ne soient pas conscient de la taille des fichiers?
$ tar cvf - le_repertoire | bzip2 -c > le_rep.tar.bz2
Je manipule des archives de plus de 5 Go sans problème (avec la version Sun de tar).
De la même façon, bzip2 refuse d'ouvrir directement des gros fichiers, mais il suffit des les ouvrir pour lui, avec des trucs comme ça:
$ bzcat < gros_fichier.bz2 > gros_fichier
-- Jérémy JUST
On Thu, 19 May 2005 14:27:30 +0200
"Rakotomandimby (R12y) Mihamina"
<mihamina.rakotomandimby@etu.univ-orleans.fr> wrote:
Sur ma Debian Sarge, je ne sais encore pourquoi, j'avais un problème
de taille de fichier. Le truc c'est que ça date (4 - 5 mois), que je
ne me souviens pas de l'erreur exacte, mais que je tentais un "tar +
compression à la volée" (tar cjf le_repertoire). Quasiment le même
problème que celui-ci.
Et tu as essayé quasiment la même solution, en utilisant des pipes
pour que les programmes ne soient pas conscient de la taille des
fichiers?
$ tar cvf - le_repertoire | bzip2 -c > le_rep.tar.bz2
Je manipule des archives de plus de 5 Go sans problème (avec la
version Sun de tar).
De la même façon, bzip2 refuse d'ouvrir directement des gros fichiers,
mais il suffit des les ouvrir pour lui, avec des trucs comme ça:
On Thu, 19 May 2005 14:27:30 +0200 "Rakotomandimby (R12y) Mihamina" wrote:
Sur ma Debian Sarge, je ne sais encore pourquoi, j'avais un problème de taille de fichier. Le truc c'est que ça date (4 - 5 mois), que je ne me souviens pas de l'erreur exacte, mais que je tentais un "tar + compression à la volée" (tar cjf le_repertoire). Quasiment le même problème que celui-ci.
Et tu as essayé quasiment la même solution, en utilisant des pipes pour que les programmes ne soient pas conscient de la taille des fichiers?
$ tar cvf - le_repertoire | bzip2 -c > le_rep.tar.bz2
Je manipule des archives de plus de 5 Go sans problème (avec la version Sun de tar).
De la même façon, bzip2 refuse d'ouvrir directement des gros fichiers, mais il suffit des les ouvrir pour lui, avec des trucs comme ça:
$ bzcat < gros_fichier.bz2 > gros_fichier
-- Jérémy JUST
Chris
Rakotomandimby (R12y) Mihamina wrote:
Bonjour
Apres avoir ete insatisfait de GNU tar, J'ai essayé cpio et recemment pax.
Celui qui ne semble m'avoir posé aucun probleme avec la taille des fichiers est cpio. Cela dit, il m'a semblé lire que cpio utilisait (par defaut) un format non libre. Le cahier des charge impose la liberté de ce format. Bon de toutes facon je devais aussi tester pax avant de decider. Et c'est la que j'en suis.
root-fctmp>>>> pax --version pax (pax) 3.0
J'ai un repertoire "toto" qui contient environ 3Go de fchiers et sous repertoires. La commande decrite par le man pour archiver est:
root-fctmp>>>> pax -w -f toto.pax ./toto
Le probleme c'est qu'au bout d'un moment (je pense a quand ca atteint 2Go) il me demande le nom de la deuxieme archive.
Pour contourner le probleme, Stephane Chazelas m'avait indiqué une astuce assez subtile (d'apres moi) qui consistait a faire ecrire pax sur stdout (ce qui l'affranchirait de calculer une taille de fichier) et de recuperer stdout dans un fichier.
root-fctmp>>>> pax -w ./toto > toto.pax
J'obtiens donc un gros fichier de 3.0G d'apres 'du -h' Je le bzip, puis le transfere chez moi.
5 heures apres...
je decompresse puis, ca passe (Ok, pas de corruption manifestement). je tente le desarchivage:
root-fctmp>>>> pax -r < toto.pax pax: Failed stat on <STDIN> <Value too large for defined data type>
ATTENTION! pax archive volume change required. Ready for archive volume: 1 Input archive name or "." to quit pax. Archive name >
C'est en fait une erreur parceque je n'ai qu'une seule archive. Et puis meme si je lui donne le nom de l'archive, il dit que ce n'est pas valable.
Bon le souci c'est que je dois donc refaire l'archive, en la splittant, et la retelecharger (re 5 heures) si je ne trouve pas un moyen de desarchiver cette chose...
Vous avez des pistes?
Et puis j'utilise un outil d'archivage moi pour avoir un seul gros fichier, et je trouve dommage qu'il m'oblige a le splitter. Pour mon usage des outil d'archivage, je trouve ca dommage...
Juste un question toute bete ton systeme de fichier peut gerer plus de 2
Go par fichier ? on dirait que le probleme vient de la ou du fabuleux ulimit ?
A+ chris
Rakotomandimby (R12y) Mihamina wrote:
Bonjour
Apres avoir ete insatisfait de GNU tar,
J'ai essayé cpio et recemment pax.
Celui qui ne semble m'avoir posé aucun probleme avec la taille des
fichiers est cpio. Cela dit, il m'a semblé lire que cpio utilisait (par
defaut) un format non libre. Le cahier des charge impose la liberté de ce
format. Bon de toutes facon je devais aussi tester pax avant de decider.
Et c'est la que j'en suis.
root-fctmp>>>> pax --version
pax (pax) 3.0
J'ai un repertoire "toto" qui contient environ 3Go de fchiers et sous
repertoires.
La commande decrite par le man pour archiver est:
root-fctmp>>>> pax -w -f toto.pax ./toto
Le probleme c'est qu'au bout d'un moment (je pense a quand ca atteint 2Go)
il me demande le nom de la deuxieme archive.
Pour contourner le probleme, Stephane Chazelas m'avait indiqué une astuce
assez subtile (d'apres moi) qui consistait a faire ecrire pax sur stdout
(ce qui l'affranchirait de calculer une taille de fichier) et de recuperer
stdout dans un fichier.
root-fctmp>>>> pax -w ./toto > toto.pax
J'obtiens donc un gros fichier de 3.0G d'apres 'du -h'
Je le bzip, puis le transfere chez moi.
5 heures apres...
je decompresse puis, ca passe (Ok, pas de corruption manifestement).
je tente le desarchivage:
root-fctmp>>>> pax -r < toto.pax
pax: Failed stat on <STDIN> <Value too large for defined data type>
ATTENTION! pax archive volume change required.
Ready for archive volume: 1
Input archive name or "." to quit pax.
Archive name >
C'est en fait une erreur parceque je n'ai qu'une seule archive.
Et puis meme si je lui donne le nom de l'archive, il dit que ce n'est pas
valable.
Bon le souci c'est que je dois donc refaire l'archive, en la splittant, et
la retelecharger (re 5 heures) si je ne trouve pas un moyen de
desarchiver cette chose...
Vous avez des pistes?
Et puis j'utilise un outil d'archivage moi pour
avoir un seul gros fichier, et je trouve dommage qu'il m'oblige a le
splitter. Pour mon usage des outil d'archivage, je trouve ca dommage...
Juste un question toute bete ton systeme de fichier peut gerer plus de 2
Go par fichier ? on dirait que le probleme vient de la ou du fabuleux
ulimit ?
Apres avoir ete insatisfait de GNU tar, J'ai essayé cpio et recemment pax.
Celui qui ne semble m'avoir posé aucun probleme avec la taille des fichiers est cpio. Cela dit, il m'a semblé lire que cpio utilisait (par defaut) un format non libre. Le cahier des charge impose la liberté de ce format. Bon de toutes facon je devais aussi tester pax avant de decider. Et c'est la que j'en suis.
root-fctmp>>>> pax --version pax (pax) 3.0
J'ai un repertoire "toto" qui contient environ 3Go de fchiers et sous repertoires. La commande decrite par le man pour archiver est:
root-fctmp>>>> pax -w -f toto.pax ./toto
Le probleme c'est qu'au bout d'un moment (je pense a quand ca atteint 2Go) il me demande le nom de la deuxieme archive.
Pour contourner le probleme, Stephane Chazelas m'avait indiqué une astuce assez subtile (d'apres moi) qui consistait a faire ecrire pax sur stdout (ce qui l'affranchirait de calculer une taille de fichier) et de recuperer stdout dans un fichier.
root-fctmp>>>> pax -w ./toto > toto.pax
J'obtiens donc un gros fichier de 3.0G d'apres 'du -h' Je le bzip, puis le transfere chez moi.
5 heures apres...
je decompresse puis, ca passe (Ok, pas de corruption manifestement). je tente le desarchivage:
root-fctmp>>>> pax -r < toto.pax pax: Failed stat on <STDIN> <Value too large for defined data type>
ATTENTION! pax archive volume change required. Ready for archive volume: 1 Input archive name or "." to quit pax. Archive name >
C'est en fait une erreur parceque je n'ai qu'une seule archive. Et puis meme si je lui donne le nom de l'archive, il dit que ce n'est pas valable.
Bon le souci c'est que je dois donc refaire l'archive, en la splittant, et la retelecharger (re 5 heures) si je ne trouve pas un moyen de desarchiver cette chose...
Vous avez des pistes?
Et puis j'utilise un outil d'archivage moi pour avoir un seul gros fichier, et je trouve dommage qu'il m'oblige a le splitter. Pour mon usage des outil d'archivage, je trouve ca dommage...
Juste un question toute bete ton systeme de fichier peut gerer plus de 2
Go par fichier ? on dirait que le probleme vient de la ou du fabuleux ulimit ?
