J'ai un serveur web (hébergé très loin de chez moi), avec un disque
dur de 70 Go.
J'ai un serveur local (samba, mail, etc.) avec un très gros disque
dur.
J'aimerais faire un backup complet du serveur web sur la machine
locale, mis à jour quotidiennement (incrémentalement bien sûr), de
telle sorte qu'en cas de crash du disque dur, je puisse fournir un
tarball complet à l'hébergeur, pour une restauration rapide.
Les permissions doivent être sauvegardées, de même que tous les
fichiers -- y compris /etc/shadow.
Je peux éventuellement me connecter sur la machine distante en tant
que root (seul compte ayant accès à tous les fichiers), mais s'il y
avait un moyen d'éviter, ça serait sympa.
Sur la machine locale, en revanche, je ne veux pas que le script de
backup tourne en root.
Or, si je récupère le fichier /etc/shadow (par exemple) avec les
droits qui vont bien, il sera modifiable uniquement par root.
Il doit y avoir une solution toute simple à côté de laquelle le
béotien que je suis est passé, mais en attendant, je patauge...
J'imagine que ce qu'il me faudrait, c'est un système de fichiers
indépendant (i.e. qui n'est pas monté "normalement", avec "mount"),
qui serait l'image parfaite du serveur web.
En fait, rsync découpe le fichier local en plusieurs blocs et il calcule les md4 correspondants. Il fait pareil avec le fichier distant. Puis il compare les md4 respectifs de chaque bloc. Si ils sont différents, il envoie le bloc en question.
À noter, un programme moins automatique mais qui rend bien des services : par2 (par2cmdline). Lui aussi découpe le fichier en blocs, mais sait chercher les blocs partout dans l'ancien fichier. Ainsi, si tu rajoutes des octets au début du fichier, ou si tu changes l'ordre des blocs dans le fichier, tu auras peu à transférer. Je m'en sers beaucoup pour mettre à jour le programme d'installation (grosso modo, un .zip autoextractible) d'un logiciel que je développe : bien souvent, le gros des fichiers de données reste identique, mais pas forcément à la même place dans l'archive, ni dans le même ordre.
Note : c'est un peu un détournement -- normalement, il sert à rajouter de la redondance à des fichiers, façon RAID-5, pour une transmission par un moyen peu fiable (Usenet par exemple) ou un stockage sur un media peu fiable (DVD-R).
On Wed, 9 Aug 2006 02:03:26 +0200, "Arol" <annie.nomat@free.fr>:
En fait, rsync découpe le fichier local en plusieurs blocs et il calcule les
md4 correspondants. Il fait pareil avec le fichier distant.
Puis il compare les md4 respectifs de chaque bloc.
Si ils sont différents, il envoie le bloc en question.
À noter, un programme moins automatique mais qui rend bien des
services : par2 (par2cmdline).
Lui aussi découpe le fichier en blocs, mais sait chercher les blocs
partout dans l'ancien fichier. Ainsi, si tu rajoutes des octets au
début du fichier, ou si tu changes l'ordre des blocs dans le fichier,
tu auras peu à transférer.
Je m'en sers beaucoup pour mettre à jour le programme d'installation
(grosso modo, un .zip autoextractible) d'un logiciel que je
développe : bien souvent, le gros des fichiers de données reste
identique, mais pas forcément à la même place dans l'archive, ni dans
le même ordre.
Note : c'est un peu un détournement -- normalement, il sert à rajouter
de la redondance à des fichiers, façon RAID-5, pour une transmission
par un moyen peu fiable (Usenet par exemple) ou un stockage sur un
media peu fiable (DVD-R).
En fait, rsync découpe le fichier local en plusieurs blocs et il calcule les md4 correspondants. Il fait pareil avec le fichier distant. Puis il compare les md4 respectifs de chaque bloc. Si ils sont différents, il envoie le bloc en question.
À noter, un programme moins automatique mais qui rend bien des services : par2 (par2cmdline). Lui aussi découpe le fichier en blocs, mais sait chercher les blocs partout dans l'ancien fichier. Ainsi, si tu rajoutes des octets au début du fichier, ou si tu changes l'ordre des blocs dans le fichier, tu auras peu à transférer. Je m'en sers beaucoup pour mettre à jour le programme d'installation (grosso modo, un .zip autoextractible) d'un logiciel que je développe : bien souvent, le gros des fichiers de données reste identique, mais pas forcément à la même place dans l'archive, ni dans le même ordre.
Note : c'est un peu un détournement -- normalement, il sert à rajouter de la redondance à des fichiers, façon RAID-5, pour une transmission par un moyen peu fiable (Usenet par exemple) ou un stockage sur un media peu fiable (DVD-R).
Nicolas George
Fabien LE LEZ wrote in message :
À noter, un programme moins automatique mais qui rend bien des services : par2 (par2cmdline). Lui aussi découpe le fichier en blocs, mais sait chercher les blocs partout dans l'ancien fichier. Ainsi, si tu rajoutes des octets au début du fichier, ou si tu changes l'ordre des blocs dans le fichier, tu auras peu à transférer. Je m'en sers beaucoup pour mettre à jour le programme d'installation (grosso modo, un .zip autoextractible) d'un logiciel que je développe : bien souvent, le gros des fichiers de données reste identique, mais pas forcément à la même place dans l'archive, ni dans le même ordre.
Ça m'étonne vraiment que tu arrives à faire ça avec par2, je ne vois vraiment pas comment ça peut marcher.
En tout cas, il y a un programme qui sert à faire précisément ça, et qui pour le coup va marcher, c'est rdiff, qui est la réimplémentation autonome de l'algorithme de rsync.
Fabien LE LEZ wrote in message
<tfeld29domtvg90famrrr98meb87uojk5o@4ax.com>:
À noter, un programme moins automatique mais qui rend bien des
services : par2 (par2cmdline).
Lui aussi découpe le fichier en blocs, mais sait chercher les blocs
partout dans l'ancien fichier. Ainsi, si tu rajoutes des octets au
début du fichier, ou si tu changes l'ordre des blocs dans le fichier,
tu auras peu à transférer.
Je m'en sers beaucoup pour mettre à jour le programme d'installation
(grosso modo, un .zip autoextractible) d'un logiciel que je
développe : bien souvent, le gros des fichiers de données reste
identique, mais pas forcément à la même place dans l'archive, ni dans
le même ordre.
Ça m'étonne vraiment que tu arrives à faire ça avec par2, je ne vois
vraiment pas comment ça peut marcher.
En tout cas, il y a un programme qui sert à faire précisément ça, et qui
pour le coup va marcher, c'est rdiff, qui est la réimplémentation autonome
de l'algorithme de rsync.
À noter, un programme moins automatique mais qui rend bien des services : par2 (par2cmdline). Lui aussi découpe le fichier en blocs, mais sait chercher les blocs partout dans l'ancien fichier. Ainsi, si tu rajoutes des octets au début du fichier, ou si tu changes l'ordre des blocs dans le fichier, tu auras peu à transférer. Je m'en sers beaucoup pour mettre à jour le programme d'installation (grosso modo, un .zip autoextractible) d'un logiciel que je développe : bien souvent, le gros des fichiers de données reste identique, mais pas forcément à la même place dans l'archive, ni dans le même ordre.
Ça m'étonne vraiment que tu arrives à faire ça avec par2, je ne vois vraiment pas comment ça peut marcher.
En tout cas, il y a un programme qui sert à faire précisément ça, et qui pour le coup va marcher, c'est rdiff, qui est la réimplémentation autonome de l'algorithme de rsync.
Fabien LE LEZ
On 10 Aug 2006 13:11:20 GMT, Nicolas George <nicolas$:
Ça m'étonne vraiment que tu arrives à faire ça avec par2, je ne vois vraiment pas comment ça peut marcher.
C'est fort simple : le vieux fichier est considéré comme "cassé" (puisque certains octets sont incorrects, par rapport au nouveau), et je demande simplement à par2 de le réparer.
rdiff
Va falloir que je jette un oeil là-dessus, effectivement.
On 10 Aug 2006 13:11:20 GMT, Nicolas George
<nicolas$george@salle-s.org>:
Ça m'étonne vraiment que tu arrives à faire ça avec par2, je ne vois
vraiment pas comment ça peut marcher.
C'est fort simple : le vieux fichier est considéré comme "cassé"
(puisque certains octets sont incorrects, par rapport au nouveau),
et je demande simplement à par2 de le réparer.
rdiff
Va falloir que je jette un oeil là-dessus, effectivement.
On 10 Aug 2006 13:11:20 GMT, Nicolas George <nicolas$:
Ça m'étonne vraiment que tu arrives à faire ça avec par2, je ne vois vraiment pas comment ça peut marcher.
C'est fort simple : le vieux fichier est considéré comme "cassé" (puisque certains octets sont incorrects, par rapport au nouveau), et je demande simplement à par2 de le réparer.
rdiff
Va falloir que je jette un oeil là-dessus, effectivement.
Nicolas George
Fabien LE LEZ wrote in message :
C'est fort simple : le vieux fichier est considéré comme "cassé" (puisque certains octets sont incorrects, par rapport au nouveau), et je demande simplement à par2 de le réparer.
Oui, mais je ne vois pas comment il peut arriver à le réparer avec peu de redondance dans les circonstances que tu décris. par2 travaille avec des blocs de taille fixe, donc si le bout de l'archive concerné a bougé d'une taille qui n'est pas multiple de la taille de bloc, c'est fiche. Et même si c'est le cas, je suis surpris que par2 arrive à se rendre compte que le bloc n+k, cassé, peut servir de bloc n intact.
Fabien LE LEZ wrote in message
<noind2tol8fh1nhfb72lk943lee0ihnvvl@4ax.com>:
C'est fort simple : le vieux fichier est considéré comme "cassé"
(puisque certains octets sont incorrects, par rapport au nouveau),
et je demande simplement à par2 de le réparer.
Oui, mais je ne vois pas comment il peut arriver à le réparer avec peu de
redondance dans les circonstances que tu décris. par2 travaille avec des
blocs de taille fixe, donc si le bout de l'archive concerné a bougé d'une
taille qui n'est pas multiple de la taille de bloc, c'est fiche. Et même si
c'est le cas, je suis surpris que par2 arrive à se rendre compte que le bloc
n+k, cassé, peut servir de bloc n intact.
C'est fort simple : le vieux fichier est considéré comme "cassé" (puisque certains octets sont incorrects, par rapport au nouveau), et je demande simplement à par2 de le réparer.
Oui, mais je ne vois pas comment il peut arriver à le réparer avec peu de redondance dans les circonstances que tu décris. par2 travaille avec des blocs de taille fixe, donc si le bout de l'archive concerné a bougé d'une taille qui n'est pas multiple de la taille de bloc, c'est fiche. Et même si c'est le cas, je suis surpris que par2 arrive à se rendre compte que le bloc n+k, cassé, peut servir de bloc n intact.
Fabien LE LEZ
On 11 Aug 2006 01:48:45 GMT, Nicolas George <nicolas$:
donc si le bout de l'archive concerné a bougé d'une taille qui n'est pas multiple de la taille de bloc, c'est fiche.
Non. Par2 découpe effectivement le nouveau fichier en blocs de taille fixe.
Mais pendant la réparation, il cherche chaque bloc dans l'intégralité de chaque fichier qu'on lui donne en paramètre, par un système de "CRC32 glissant". Il se sert du hash CRC32 pour repérer un candidat, puis vérifie que le candidat est réellement le bloc cherché en vérifiant le MD5.
On 11 Aug 2006 01:48:45 GMT, Nicolas George
<nicolas$george@salle-s.org>:
donc si le bout de l'archive concerné a bougé d'une
taille qui n'est pas multiple de la taille de bloc, c'est fiche.
Non.
Par2 découpe effectivement le nouveau fichier en blocs de taille fixe.
Mais pendant la réparation, il cherche chaque bloc dans l'intégralité
de chaque fichier qu'on lui donne en paramètre, par un système de
"CRC32 glissant".
Il se sert du hash CRC32 pour repérer un candidat, puis vérifie que le
candidat est réellement le bloc cherché en vérifiant le MD5.
On 11 Aug 2006 01:48:45 GMT, Nicolas George <nicolas$:
donc si le bout de l'archive concerné a bougé d'une taille qui n'est pas multiple de la taille de bloc, c'est fiche.
Non. Par2 découpe effectivement le nouveau fichier en blocs de taille fixe.
Mais pendant la réparation, il cherche chaque bloc dans l'intégralité de chaque fichier qu'on lui donne en paramètre, par un système de "CRC32 glissant". Il se sert du hash CRC32 pour repérer un candidat, puis vérifie que le candidat est réellement le bloc cherché en vérifiant le MD5.
gvdmoort
Fabien LE LEZ schreef:
On 9 Aug 2006 00:25:49 -0700, :
Quant au fait de compresser ou non cette archive, j'ai "fréquenté" un serveur de backup qui créait un tar.gz sur le même disque que les données: il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée, et que l'originale n'est effacée que lorsque la compression est achevée.
Hon ?
Si tu fais un tar c * | bzip2 > archive.bz2 tu es assuré qu'il n'y aura aucune copie superflue.
À voir... Je te parle d'une archive de plusieurs gigas, la compression ne se faisait pas instantanément, donc, en listant les fichiers du répertoires pour voir l'avancement des travaux, je constatais l'existence des deux fichiers. c'est d'ailleurs une saine logique de ne pas altérer l'original avant que la compression soit achevée.
Est-ce que tu as vérifié qu'il n'en était pas ainsi avec bzip2 ? ça voudrait dire qu'il "rogne" le fichier original au fur à mesure qu'il crée la copie compressée. Je vérifierai sur ma linuxette ce soir, mais ça m'étonnerait.
Gvdmoort
Fabien LE LEZ schreef:
On 9 Aug 2006 00:25:49 -0700, gvdmoort@skynet.be:
Quant au fait de compresser ou non cette archive, j'ai "fréquenté" un
serveur de backup qui créait un tar.gz sur le même disque que les
données: il faut savoir que l'archive tar est créée, puis qu'une
copie en est faite, que celle-ci est compressée, et que l'originale
n'est effacée que lorsque la compression est achevée.
Hon ?
Si tu fais un
tar c * | bzip2 > archive.bz2
tu es assuré qu'il n'y aura aucune copie superflue.
À voir... Je te parle d'une archive de plusieurs gigas, la compression
ne se faisait pas instantanément, donc, en listant les fichiers du
répertoires pour voir l'avancement des travaux, je constatais
l'existence des deux fichiers. c'est d'ailleurs une saine logique de ne
pas altérer l'original avant que la compression soit achevée.
Est-ce que tu as vérifié qu'il n'en était pas ainsi avec bzip2 ? ça
voudrait dire qu'il "rogne" le fichier original au fur à mesure qu'il
crée la copie compressée. Je vérifierai sur ma linuxette ce soir,
mais ça m'étonnerait.
Quant au fait de compresser ou non cette archive, j'ai "fréquenté" un serveur de backup qui créait un tar.gz sur le même disque que les données: il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée, et que l'originale n'est effacée que lorsque la compression est achevée.
Hon ?
Si tu fais un tar c * | bzip2 > archive.bz2 tu es assuré qu'il n'y aura aucune copie superflue.
À voir... Je te parle d'une archive de plusieurs gigas, la compression ne se faisait pas instantanément, donc, en listant les fichiers du répertoires pour voir l'avancement des travaux, je constatais l'existence des deux fichiers. c'est d'ailleurs une saine logique de ne pas altérer l'original avant que la compression soit achevée.
Est-ce que tu as vérifié qu'il n'en était pas ainsi avec bzip2 ? ça voudrait dire qu'il "rogne" le fichier original au fur à mesure qu'il crée la copie compressée. Je vérifierai sur ma linuxette ce soir, mais ça m'étonnerait.
Gvdmoort
Nicolas George
wrote in message :
il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée
Non, certainement pas. Apparemment, il y a une chose que tu n'as pas comprise au sujet de la compression de données. Comprimer des données, ce n'est pas changer ces données pour les rendre plus petites. C'est créer de _nouvelles_ données qui expriment la même chose de manière plus compacte.
Ce que tu as pris pour une copie des données originales était le fichier compressé en cours de construction, mais la compression se faisait à partir du fichier original, sans copie.
tar c * | bzip2 > archive.bz2 Est-ce que tu as vérifié qu'il n'en était pas ainsi avec bzip2 ? ça
voudrait dire qu'il "rogne" le fichier original au fur à mesure qu'il crée la copie compressée. Je vérifierai sur ma linuxette ce soir, mais ça m'étonnerait.
Une compréhension élémentaire du fonctionnement des commandes Unix suffit à se rendre compte que ce n'est pas du tout ça. Il n'y a pas de « fichier original » ici. tar produit ses données et les écrit directement à bzip2, qui les compresse et les écrit directement dans archive.bz2 ; les données non compressées ne sont jamais stockées nulle part.
C'est possible parce que bzip2, tout comme gzip d'ailleurs, travaille en flux : la compression d'un bout de données dépend des données qui précèdent, mais pas des données qui suivent, ce qui permet de compresser progressivement et à la volée, avec un tampon de stockage très limité. Ce ne serait pas le cas pour une compression Huffmann pure, par exemple, parce qu'elle nécessite des statistiques sur l'ensemble des données avant de commencer.
gvdmoort@skynet.be wrote in message
<1155288947.026524.207800@p79g2000cwp.googlegroups.com>:
il faut savoir que l'archive tar est créée, puis qu'une
copie en est faite, que celle-ci est compressée
Non, certainement pas. Apparemment, il y a une chose que tu n'as pas
comprise au sujet de la compression de données. Comprimer des données, ce
n'est pas changer ces données pour les rendre plus petites. C'est créer de
_nouvelles_ données qui expriment la même chose de manière plus compacte.
Ce que tu as pris pour une copie des données originales était le fichier
compressé en cours de construction, mais la compression se faisait à partir
du fichier original, sans copie.
tar c * | bzip2 > archive.bz2
Est-ce que tu as vérifié qu'il n'en était pas ainsi avec bzip2 ? ça
voudrait dire qu'il "rogne" le fichier original au fur à mesure qu'il
crée la copie compressée. Je vérifierai sur ma linuxette ce soir,
mais ça m'étonnerait.
Une compréhension élémentaire du fonctionnement des commandes Unix suffit à
se rendre compte que ce n'est pas du tout ça. Il n'y a pas de « fichier
original » ici. tar produit ses données et les écrit directement à bzip2,
qui les compresse et les écrit directement dans archive.bz2 ; les données
non compressées ne sont jamais stockées nulle part.
C'est possible parce que bzip2, tout comme gzip d'ailleurs, travaille en
flux : la compression d'un bout de données dépend des données qui précèdent,
mais pas des données qui suivent, ce qui permet de compresser
progressivement et à la volée, avec un tampon de stockage très limité. Ce ne
serait pas le cas pour une compression Huffmann pure, par exemple, parce
qu'elle nécessite des statistiques sur l'ensemble des données avant de
commencer.
il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée
Non, certainement pas. Apparemment, il y a une chose que tu n'as pas comprise au sujet de la compression de données. Comprimer des données, ce n'est pas changer ces données pour les rendre plus petites. C'est créer de _nouvelles_ données qui expriment la même chose de manière plus compacte.
Ce que tu as pris pour une copie des données originales était le fichier compressé en cours de construction, mais la compression se faisait à partir du fichier original, sans copie.
tar c * | bzip2 > archive.bz2 Est-ce que tu as vérifié qu'il n'en était pas ainsi avec bzip2 ? ça
voudrait dire qu'il "rogne" le fichier original au fur à mesure qu'il crée la copie compressée. Je vérifierai sur ma linuxette ce soir, mais ça m'étonnerait.
Une compréhension élémentaire du fonctionnement des commandes Unix suffit à se rendre compte que ce n'est pas du tout ça. Il n'y a pas de « fichier original » ici. tar produit ses données et les écrit directement à bzip2, qui les compresse et les écrit directement dans archive.bz2 ; les données non compressées ne sont jamais stockées nulle part.
C'est possible parce que bzip2, tout comme gzip d'ailleurs, travaille en flux : la compression d'un bout de données dépend des données qui précèdent, mais pas des données qui suivent, ce qui permet de compresser progressivement et à la volée, avec un tampon de stockage très limité. Ce ne serait pas le cas pour une compression Huffmann pure, par exemple, parce qu'elle nécessite des statistiques sur l'ensemble des données avant de commencer.
Vincent Bernat
OoO En cette fin de matinée radieuse du vendredi 11 août 2006, vers 11:35, disait:
Si tu fais un tar c * | bzip2 > archive.bz2 tu es assuré qu'il n'y aura aucune copie superflue.
À voir... Je te parle d'une archive de plusieurs gigas, la compression ne se faisait pas instantanément, donc, en listant les fichiers du répertoires pour voir l'avancement des travaux, je constatais l'existence des deux fichiers. c'est d'ailleurs une saine logique de ne pas altérer l'original avant que la compression soit achevée.
Est-ce que tu as vérifié qu'il n'en était pas ainsi avec bzip2 ? ça voudrait dire qu'il "rogne" le fichier original au fur à mesure qu'il crée la copie compressée. Je vérifierai sur ma linuxette ce soir, mais ça m'étonnerait.
gzip et bzip2 sont prévus pour fonctionner également sur des flux, sans passage par un fichier temporaire dans ce cas. Tu peux t'en assurer avec cette commande : dd if=/dev/zero | strace -eopen bzip2 > /dev/null
La compression est aussi efficace. Je suppose toutefois que cela prend plus de mémoire.
Une autre propriété intéressante est que tu peux couper un fichier en deux, gzipper les deux parties et concaténer le résultat. Si tu dégzippes, tu obtiens ton fichier original. -- I WILL NOT DEFAME NEW ORLEANS I WILL NOT DEFAME NEW ORLEANS I WILL NOT DEFAME NEW ORLEANS -+- Bart Simpson on chalkboard in episode 9F01
OoO En cette fin de matinée radieuse du vendredi 11 août 2006, vers
11:35, gvdmoort@skynet.be disait:
Si tu fais un
tar c * | bzip2 > archive.bz2
tu es assuré qu'il n'y aura aucune copie superflue.
À voir... Je te parle d'une archive de plusieurs gigas, la compression
ne se faisait pas instantanément, donc, en listant les fichiers du
répertoires pour voir l'avancement des travaux, je constatais
l'existence des deux fichiers. c'est d'ailleurs une saine logique de ne
pas altérer l'original avant que la compression soit achevée.
Est-ce que tu as vérifié qu'il n'en était pas ainsi avec bzip2 ? ça
voudrait dire qu'il "rogne" le fichier original au fur à mesure qu'il
crée la copie compressée. Je vérifierai sur ma linuxette ce soir,
mais ça m'étonnerait.
gzip et bzip2 sont prévus pour fonctionner également sur des flux,
sans passage par un fichier temporaire dans ce cas. Tu peux t'en
assurer avec cette commande :
dd if=/dev/zero | strace -eopen bzip2 > /dev/null
La compression est aussi efficace. Je suppose toutefois que cela prend
plus de mémoire.
Une autre propriété intéressante est que tu peux couper un fichier en
deux, gzipper les deux parties et concaténer le résultat. Si tu
dégzippes, tu obtiens ton fichier original.
--
I WILL NOT DEFAME NEW ORLEANS
I WILL NOT DEFAME NEW ORLEANS
I WILL NOT DEFAME NEW ORLEANS
-+- Bart Simpson on chalkboard in episode 9F01
OoO En cette fin de matinée radieuse du vendredi 11 août 2006, vers 11:35, disait:
Si tu fais un tar c * | bzip2 > archive.bz2 tu es assuré qu'il n'y aura aucune copie superflue.
À voir... Je te parle d'une archive de plusieurs gigas, la compression ne se faisait pas instantanément, donc, en listant les fichiers du répertoires pour voir l'avancement des travaux, je constatais l'existence des deux fichiers. c'est d'ailleurs une saine logique de ne pas altérer l'original avant que la compression soit achevée.
Est-ce que tu as vérifié qu'il n'en était pas ainsi avec bzip2 ? ça voudrait dire qu'il "rogne" le fichier original au fur à mesure qu'il crée la copie compressée. Je vérifierai sur ma linuxette ce soir, mais ça m'étonnerait.
gzip et bzip2 sont prévus pour fonctionner également sur des flux, sans passage par un fichier temporaire dans ce cas. Tu peux t'en assurer avec cette commande : dd if=/dev/zero | strace -eopen bzip2 > /dev/null
La compression est aussi efficace. Je suppose toutefois que cela prend plus de mémoire.
Une autre propriété intéressante est que tu peux couper un fichier en deux, gzipper les deux parties et concaténer le résultat. Si tu dégzippes, tu obtiens ton fichier original. -- I WILL NOT DEFAME NEW ORLEANS I WILL NOT DEFAME NEW ORLEANS I WILL NOT DEFAME NEW ORLEANS -+- Bart Simpson on chalkboard in episode 9F01
Nicolas George
Vincent Bernat wrote in message :
Je suppose toutefois que cela prend plus de mémoire.
Non, c'est exactement pareil. La compression par flux est le mode normal, et le seul mode, de fonctionnement de gzip. Travailler explicitement sur le fichier apporte uniquement de la simplicité d'intendance : calcul du nouveau nom de fichier, préservation des permissions.
Vincent Bernat wrote in message <m3irkz61mb.fsf@neo.luffy.cx>:
Je suppose toutefois que cela prend
plus de mémoire.
Non, c'est exactement pareil. La compression par flux est le mode normal, et
le seul mode, de fonctionnement de gzip. Travailler explicitement sur le
fichier apporte uniquement de la simplicité d'intendance : calcul du nouveau
nom de fichier, préservation des permissions.
Je suppose toutefois que cela prend plus de mémoire.
Non, c'est exactement pareil. La compression par flux est le mode normal, et le seul mode, de fonctionnement de gzip. Travailler explicitement sur le fichier apporte uniquement de la simplicité d'intendance : calcul du nouveau nom de fichier, préservation des permissions.
gvdmoort
Re-bonjour,
wrote in message :
il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée
Non, certainement pas. Apparemment, il y a une chose que tu n'as pas comprise au sujet de la compression de données. Comprimer des données , ce n'est pas changer ces données pour les rendre plus petites. C'est cré er de _nouvelles_ données qui expriment la même chose de manière plus com pacte.
Ce que tu as pris pour une copie des données originales était le fich ier compressé en cours de construction, mais la compression se faisait à partir du fichier original, sans copie.
Peut-être que je m'exprime mal, parce que justement j'ai recontré des personnes qui croient que c'est "changer ces données pour les rendre plus petites", un peu comme si on les poussait par un bout pour les tasser. Puisque gzip, comme tu l'écris, "construit" un fichier compressé à partir du "fichier original", ça veut quand même dire qu'à un moment donné, on a sur le disque, simultanément, même briêvement, le fichier original ET le fichier compressé. Donc, j'exagérais en disant qu'il fallait pouvoir stocker 3x le volume de données, mais si la compression atteint par ex. un taux de 50%, on arrive quand même à 2,5
Bàt,
Gvdmoort
Re-bonjour,
gvdmoort@skynet.be wrote in message
<1155288947.026524.207800@p79g2000cwp.googlegroups.com>:
il faut savoir que l'archive tar est créée, puis qu'une
copie en est faite, que celle-ci est compressée
Non, certainement pas. Apparemment, il y a une chose que tu n'as pas
comprise au sujet de la compression de données. Comprimer des données , ce
n'est pas changer ces données pour les rendre plus petites. C'est cré er de
_nouvelles_ données qui expriment la même chose de manière plus com pacte.
Ce que tu as pris pour une copie des données originales était le fich ier
compressé en cours de construction, mais la compression se faisait à partir
du fichier original, sans copie.
Peut-être que je m'exprime mal, parce que justement j'ai recontré des
personnes qui croient que c'est "changer ces données pour les rendre
plus petites", un peu comme si on les poussait par un bout pour les
tasser. Puisque gzip, comme tu l'écris, "construit" un fichier
compressé à partir du "fichier original", ça veut quand même dire
qu'à un moment donné, on a sur le disque, simultanément, même
briêvement, le fichier original ET le fichier compressé. Donc,
j'exagérais en disant qu'il fallait pouvoir stocker 3x le volume de
données, mais si la compression atteint par ex. un taux de 50%, on
arrive quand même à 2,5
il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée
Non, certainement pas. Apparemment, il y a une chose que tu n'as pas comprise au sujet de la compression de données. Comprimer des données , ce n'est pas changer ces données pour les rendre plus petites. C'est cré er de _nouvelles_ données qui expriment la même chose de manière plus com pacte.
Ce que tu as pris pour une copie des données originales était le fich ier compressé en cours de construction, mais la compression se faisait à partir du fichier original, sans copie.
Peut-être que je m'exprime mal, parce que justement j'ai recontré des personnes qui croient que c'est "changer ces données pour les rendre plus petites", un peu comme si on les poussait par un bout pour les tasser. Puisque gzip, comme tu l'écris, "construit" un fichier compressé à partir du "fichier original", ça veut quand même dire qu'à un moment donné, on a sur le disque, simultanément, même briêvement, le fichier original ET le fichier compressé. Donc, j'exagérais en disant qu'il fallait pouvoir stocker 3x le volume de données, mais si la compression atteint par ex. un taux de 50%, on arrive quand même à 2,5
