En recherchant psync via gougueule, j'ai vu que Tiger disposait d'un
utilitaire équivalent, rsync...
J'ai fait un premier test rapide, un dossier en local, et un dossier sur
un disque dur externe à synchroniser
bon, rsync -vr ça marche pas mal, surtout si on droppe les noms des
dossiers à synchro sur la fenêtre du Terminal ;-)
qq petits bémols quand même :
- on dirait que ça ne préserve pas la branche des données...
- j'ai voulu enregistrer la commande sous forme d'un fichier texte, mais
quand je colle le contenu du fichier texte, il ne m'interprète pas les
espaces dans le nom du dossier -- à éviter donc, j'ai mis un underscore
à la place
sinon, c'est hachement plus rapide que la copie Fider ;-)))
PS : please, si vous répondez, que ça soit au ras des pâquerettes, je
suis total nioubie pour la ligne de commande !
--
Qu'est-ce qu'on fout là tous, dans ce petit coin d'Univers ?
C'est à dire que ça fait de la synchro, et même que si tu as par exemple une iso de 600Mo et que tu as changé 3 fichiers de quelques ko dedant il ne copies que la différence de quelques ko, pas tout le fichier.
Tu veux dire qu'il ne copie que les 3 fichiers changés, n'est-ce-pas ? (en ce basant sur les dates de modif)
non, c'est encore plus fort : Il ne copie que ce qui a changé entre un fichier et un autre, pas tout le fichier.
T'es sûr de toi là ?
FiLH
C'est la théorie : il génère un patch qui n'inclut que ce qui a changé dans un fichier, pas tout le fichier.
A présent c'est assez facile à vérifier, si j'ai un peu de temps demain je m'y colle.
J'avoue que ça me semble un peu lourd, mais après tout pourquoi pas..
FiLH -- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Nicolas MICHEL <Nicolas.Michel@bonbon.net> wrote:
FiLH <filh@filh.orgie> wrote:
Nicolas MICHEL <Nicolas.Michel@bonbon.net> wrote:
JPaul <blanc@empty.org> wrote:
Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:
C'est à dire que ça fait de la synchro, et même que si tu as par
exemple une iso de 600Mo et que tu as changé 3 fichiers de
quelques ko dedant il ne copies que la différence de quelques ko,
pas tout le fichier.
Tu veux dire qu'il ne copie que les 3 fichiers changés, n'est-ce-pas ?
(en ce basant sur les dates de modif)
non, c'est encore plus fort :
Il ne copie que ce qui a changé entre un fichier et un autre, pas tout
le fichier.
T'es sûr de toi là ?
FiLH
C'est la théorie : il génère un patch qui n'inclut que ce qui a changé
dans un fichier, pas tout le fichier.
A présent c'est assez facile à vérifier, si j'ai un peu de temps demain
je m'y colle.
J'avoue que ça me semble un peu lourd, mais après tout pourquoi pas..
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
C'est à dire que ça fait de la synchro, et même que si tu as par exemple une iso de 600Mo et que tu as changé 3 fichiers de quelques ko dedant il ne copies que la différence de quelques ko, pas tout le fichier.
Tu veux dire qu'il ne copie que les 3 fichiers changés, n'est-ce-pas ? (en ce basant sur les dates de modif)
non, c'est encore plus fort : Il ne copie que ce qui a changé entre un fichier et un autre, pas tout le fichier.
T'es sûr de toi là ?
FiLH
C'est la théorie : il génère un patch qui n'inclut que ce qui a changé dans un fichier, pas tout le fichier.
A présent c'est assez facile à vérifier, si j'ai un peu de temps demain je m'y colle.
J'avoue que ça me semble un peu lourd, mais après tout pourquoi pas..
FiLH -- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
laurent.pertois
Ludovic Cynomys wrote:
Apple a flingué son rsync avec la dernière mise à jour de sécurité. Va savoir si d'autres options ont subi le même sort.
Ben, j'ai dû passer à travers... car ç'a marché, chez moi !
Ah ?
je vérifie... aaaah, je n'ai pas encore installé 2006-002 !!!
Non, elle corrige le bug, celle-là.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Apple a flingué son rsync avec la dernière mise à jour de sécurité.
Va savoir si d'autres options ont subi le même sort.
Ben, j'ai dû passer à travers... car ç'a marché, chez moi !
Ah ?
je vérifie... aaaah, je n'ai pas encore installé 2006-002 !!!
Non, elle corrige le bug, celle-là.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Apple a flingué son rsync avec la dernière mise à jour de sécurité. Va savoir si d'autres options ont subi le même sort.
Ben, j'ai dû passer à travers... car ç'a marché, chez moi !
Ah ?
je vérifie... aaaah, je n'ai pas encore installé 2006-002 !!!
Non, elle corrige le bug, celle-là.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas Pouillon
FiLH wrote:
Nicolas MICHEL wrote:
non, c'est encore plus fort : Il ne copie que ce qui a changé entre un fichier et un autre, pas to ut le fichier.
T'es sûr de toi là ?
C'est la théorie : il génère un patch qui n'inclut que ce qui a c hangé dans un fichier, pas tout le fichier.
A présent c'est assez facile à vérifier, si j'ai un peu de temps demain je m'y colle.
Peut-être se référer à la théorie suffira... http://rsync.samba.org/tech_report/
bon, il en copie un peu plus, mais un minimum. Prenons un cas ou un client (c) se met à jour sur un serveur (s) -c calcule des checksums tournants et par blocs de son fichier actuel -c envoie tout ca a s (c'est assez réduit) -s calcule les memes choses avec sa copie du fichier et crée un patch, en gardant un max de blocs entiers venant de la version actuelle de c -s envoie le patch en une passe -c patche son fichier
Seuls les blocs changeants et les trous entre les blocs présents sur c sont transférés. On transfere donc les _blocs_ contenant des changements, donc plus que les changements seuls.
Par contre, il n'y a qu'un seul aller-retour c-s-c, et il est minimal pour ce proto (on pourrait probablement faire plus concis en volume, mais en plus de temps et d'echanges en introduisant plus de latence, ce qui n'a pas d'intéret, car probablement plus long que le transfert)
FiLH <filh@filh.orgie> wrote:
Nicolas MICHEL <Nicolas.Michel@bonbon.net> wrote:
non, c'est encore plus fort :
Il ne copie que ce qui a changé entre un fichier et un autre, pas to ut
le fichier.
T'es sûr de toi là ?
C'est la théorie : il génère un patch qui n'inclut que ce qui a c hangé
dans un fichier, pas tout le fichier.
A présent c'est assez facile à vérifier, si j'ai un peu de temps demain
je m'y colle.
Peut-être se référer à la théorie suffira...
http://rsync.samba.org/tech_report/
bon, il en copie un peu plus, mais un minimum. Prenons un cas ou un
client (c) se met à jour sur un serveur (s)
-c calcule des checksums tournants et par blocs de son fichier actuel
-c envoie tout ca a s (c'est assez réduit)
-s calcule les memes choses avec sa copie du fichier et crée un patch,
en gardant un max de blocs entiers venant de la version actuelle de c
-s envoie le patch en une passe
-c patche son fichier
Seuls les blocs changeants et les trous entre les blocs présents sur c
sont transférés. On transfere donc les _blocs_ contenant des
changements, donc plus que les changements seuls.
Par contre, il n'y a qu'un seul aller-retour c-s-c, et il est minimal
pour ce proto (on pourrait probablement faire plus concis en volume,
mais en plus de temps et d'echanges en introduisant plus de latence, ce
qui n'a pas d'intéret, car probablement plus long que le transfert)
non, c'est encore plus fort : Il ne copie que ce qui a changé entre un fichier et un autre, pas to ut le fichier.
T'es sûr de toi là ?
C'est la théorie : il génère un patch qui n'inclut que ce qui a c hangé dans un fichier, pas tout le fichier.
A présent c'est assez facile à vérifier, si j'ai un peu de temps demain je m'y colle.
Peut-être se référer à la théorie suffira... http://rsync.samba.org/tech_report/
bon, il en copie un peu plus, mais un minimum. Prenons un cas ou un client (c) se met à jour sur un serveur (s) -c calcule des checksums tournants et par blocs de son fichier actuel -c envoie tout ca a s (c'est assez réduit) -s calcule les memes choses avec sa copie du fichier et crée un patch, en gardant un max de blocs entiers venant de la version actuelle de c -s envoie le patch en une passe -c patche son fichier
Seuls les blocs changeants et les trous entre les blocs présents sur c sont transférés. On transfere donc les _blocs_ contenant des changements, donc plus que les changements seuls.
Par contre, il n'y a qu'un seul aller-retour c-s-c, et il est minimal pour ce proto (on pourrait probablement faire plus concis en volume, mais en plus de temps et d'echanges en introduisant plus de latence, ce qui n'a pas d'intéret, car probablement plus long que le transfert)
filh
Nicolas Pouillon wrote:
FiLH wrote:
Nicolas MICHEL wrote:
non, c'est encore plus fort : Il ne copie que ce qui a changé entre un fichier et un autre, pas tout le fichier.
T'es sûr de toi là ?
C'est la théorie : il génère un patch qui n'inclut que ce qui a changé dans un fichier, pas tout le fichier.
A présent c'est assez facile à vérifier, si j'ai un peu de temps demain je m'y colle.
Peut-être se référer à la théorie suffira... http://rsync.samba.org/tech_report/
bon, il en copie un peu plus, mais un minimum. Prenons un cas ou un client (c) se met à jour sur un serveur (s) -c calcule des checksums tournants et par blocs de son fichier actuel
Ok... juste un détail : faut préciser quand on parle de bloc dans un fichier, c'est habituellement une notion différente.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Nicolas Pouillon <nipo-fornews@ssji.net> wrote:
FiLH <filh@filh.orgie> wrote:
Nicolas MICHEL <Nicolas.Michel@bonbon.net> wrote:
non, c'est encore plus fort :
Il ne copie que ce qui a changé entre un fichier et un autre, pas tout
le fichier.
T'es sûr de toi là ?
C'est la théorie : il génère un patch qui n'inclut que ce qui a changé
dans un fichier, pas tout le fichier.
A présent c'est assez facile à vérifier, si j'ai un peu de temps demain
je m'y colle.
Peut-être se référer à la théorie suffira...
http://rsync.samba.org/tech_report/
bon, il en copie un peu plus, mais un minimum. Prenons un cas ou un
client (c) se met à jour sur un serveur (s)
-c calcule des checksums tournants et par blocs de son fichier actuel
Ok... juste un détail : faut préciser quand on parle de bloc dans un
fichier, c'est habituellement une notion différente.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
non, c'est encore plus fort : Il ne copie que ce qui a changé entre un fichier et un autre, pas tout le fichier.
T'es sûr de toi là ?
C'est la théorie : il génère un patch qui n'inclut que ce qui a changé dans un fichier, pas tout le fichier.
A présent c'est assez facile à vérifier, si j'ai un peu de temps demain je m'y colle.
Peut-être se référer à la théorie suffira... http://rsync.samba.org/tech_report/
bon, il en copie un peu plus, mais un minimum. Prenons un cas ou un client (c) se met à jour sur un serveur (s) -c calcule des checksums tournants et par blocs de son fichier actuel
Ok... juste un détail : faut préciser quand on parle de bloc dans un fichier, c'est habituellement une notion différente.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
je vérifie... aaaah, je n'ai pas encore installé 2006-002 !!!
Non, elle corrige le bug, celle-là.
oui, j'ai compris, après ;-)
bon, je débarque un peu... je commençais à peine à utiliser rsync, sans savoir qu'il était buggé -- et heureusement, je n'avais pas encore utilisé la fonctionnalité buggée !
je vérifie... aaaah, je n'ai pas encore installé 2006-002 !!!
Non, elle corrige le bug, celle-là.
oui, j'ai compris, après ;-)
bon, je débarque un peu... je commençais à peine à utiliser rsync, sans
savoir qu'il était buggé -- et heureusement, je n'avais pas encore
utilisé la fonctionnalité buggée !
je vérifie... aaaah, je n'ai pas encore installé 2006-002 !!!
Non, elle corrige le bug, celle-là.
oui, j'ai compris, après ;-)
bon, je débarque un peu... je commençais à peine à utiliser rsync, sans savoir qu'il était buggé -- et heureusement, je n'avais pas encore utilisé la fonctionnalité buggée !
-- je comprends vite, mais il me faut le temps
ludovic.cynomys
Frédérique & Hervé Sainct wrote:
tu peux dire que tu préfères les lignes de commandes, mais ce n'est pas la peine de qualifier les développeurs de manière méprisante.
<snip>
loin de moi cette idée... faudrait déjà arriver à en faire autant ;->
et je ne "préfère" pas la ligne de commande ! quand elle bien "encapsulée", c'est pas mal aussi...
-- Qu'est-ce qu'on fout là tous, dans ce petit coin d'Univers ?
tu peux dire que tu préfères les lignes de commandes, mais ce n'est pas la peine de qualifier les développeurs de manière méprisante.
<snip>
loin de moi cette idée... faudrait déjà arriver à en faire autant ;->
et je ne "préfère" pas la ligne de commande ! quand elle bien "encapsulée", c'est pas mal aussi...
-- Qu'est-ce qu'on fout là tous, dans ce petit coin d'Univers ?
laurent.pertois
Ludovic Cynomys wrote:
je comprends vite, mais il me faut le temps
Ca arrive à tout le monde ça :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
