rsync c'est que c'est surtout intéressant pour les transferts réseau entre 2 machines
- la machine qui envoie les données, lit son fichier, calcul une somme de contrôle sur un bloc de données
- cette somme est envoyée à l'autre machine qui va lire le même bloc de données de son côté, calculer la somme de contrôle et la comparer avec celle qui a été reçue
- si les 2 sommes de contrôle sont différentes, ce bloc du fichier est donc différent, il est donc transféré, sinon on passe au bloc de données suivant
C'est presque ça. Pour étaler ma culture : c'est la machine qui reçoit qui calcule la somme de contrôle de ses blocs ({[0;N[, [N;2*N[, [2*N;3*N[, ...}), et transmet cette liste à la machine qui envoie. Celle qui envoie cherche des endroits (à chaque octet, et non pas uniquement aux octets {0, N, 2*N, ...}, ce qui permet de gérer efficacement le cas où un octet aurait été inséré au début d'un fichier) où l'on a N octets consécutifs qui donneraient une des sommes de contrôles trouvées. Ensuite, est transmis des instructions pouvant être une suite d'octets à écrire littéralement, ou bien l'écriture d'un des blocs qui existe déjà du côté récepteur. (voir Rsync#Algorithme)
mais je crois bien qu'avec un fichier chiffré, le moindre octet modifié fait que l'ensemble du fichier est différent, ce qui rend l'option de copie différentielle encore moins intéressante qu'une copie intégrale
Pour du chiffrement de fichiers qui ne changent pas aussi souvent qu'un disque ou de petits fichiers, vous avez raison. On s'arrange (avec CBC par exemple) pour qu'un bloc chiffré ne ressemble pas à un autre même si son texte clair est identique (exemple imagé).
En revanche, pour le chiffrement d'un disque, c'est impraticable : imaginez si changer le premier octet de votre disque de 500 Go vous forçait à réécrire 500 Go ! On a par contre une technique pour au moins empêcher que 2 blocs clairs identiques ne soient aussi identiques une fois chiffrés. Pour cela, on ajoute au chiffrement une donnée qui dépend de la position (pour être précis, on réinitialise CBC (ou autre mode) à chaque secteur disque, avec un vecteur d'initialisation qui dépend de la position) (Voir également en:Disk_encryption_theory)
si tu fais un rsync entre 2 répertoires d'une même machine, tu es tout de même obligé de lire les 2 fichiers pour faire la comparaison avant d'écrire, ça n'est intéressant que si la lecture est nettement plus rapide que l'écriture (ou dans ton cas pour épargner tes cellules de flash)
Effectivement, rsync fait plus de travail qu'il n'est nécessaire (chercher à faire correspondre un bloc à une position à une autre position notamment, alors qu'il est impossible qu'un bloc chiffré se retrouve ailleurs identique). Si la lecture est vraiment plus rapide ou vraiment plus économique (sans doute pour une clef USB), alors un outil qui se contente de comparer les octets 1 à 1 (ou par secteurs) et réécrire uniquement ceux qui sont différents est ce qu'il faut. Sinon, "cp" (ou dd) est l'outil qu'il vous faut.
[^] # Re: diff
Posté par BFG . En réponse au message Logiciel de mise à jour de fichier. Évalué à 3. Dernière modification le 03 décembre 2011 à 00:31.
C'est presque ça. Pour étaler ma culture : c'est la machine qui reçoit qui calcule la somme de contrôle de ses blocs ({[0;N[, [N;2*N[, [2*N;3*N[, ...}), et transmet cette liste à la machine qui envoie. Celle qui envoie cherche des endroits (à chaque octet, et non pas uniquement aux octets {0, N, 2*N, ...}, ce qui permet de gérer efficacement le cas où un octet aurait été inséré au début d'un fichier) où l'on a N octets consécutifs qui donneraient une des sommes de contrôles trouvées. Ensuite, est transmis des instructions pouvant être une suite d'octets à écrire littéralement, ou bien l'écriture d'un des blocs qui existe déjà du côté récepteur. (voir Rsync#Algorithme)
Pour du chiffrement de fichiers qui ne changent pas aussi souvent qu'un disque ou de petits fichiers, vous avez raison. On s'arrange (avec CBC par exemple) pour qu'un bloc chiffré ne ressemble pas à un autre même si son texte clair est identique (exemple imagé).
En revanche, pour le chiffrement d'un disque, c'est impraticable : imaginez si changer le premier octet de votre disque de 500 Go vous forçait à réécrire 500 Go ! On a par contre une technique pour au moins empêcher que 2 blocs clairs identiques ne soient aussi identiques une fois chiffrés. Pour cela, on ajoute au chiffrement une donnée qui dépend de la position (pour être précis, on réinitialise CBC (ou autre mode) à chaque secteur disque, avec un vecteur d'initialisation qui dépend de la position) (Voir également en:Disk_encryption_theory)
Effectivement, rsync fait plus de travail qu'il n'est nécessaire (chercher à faire correspondre un bloc à une position à une autre position notamment, alors qu'il est impossible qu'un bloc chiffré se retrouve ailleurs identique). Si la lecture est vraiment plus rapide ou vraiment plus économique (sans doute pour une clef USB), alors un outil qui se contente de comparer les octets 1 à 1 (ou par secteurs) et réécrire uniquement ceux qui sont différents est ce qu'il faut. Sinon, "cp" (ou dd) est l'outil qu'il vous faut.