L'option rsync --iconv sur Mac ne fonctionne pas (synchronisation du serveur Linux distant vers le Mac local)

Je souhaite utiliser rsync pour sauvegarder les données d'un serveur Linux distant sur mon Mac local. Et je veux initialiser cette opération sur mon Mac local. Tout fonctionne bien sauf qu'il y a un problème de caractère spécial: chaque fois que je relance l'opération rsync (après la synchronisation initiale), les fichiers avec des caractères spéciaux sont d'abord supprimés puis resynchronisés. Pour autant que je comprends, il y a un problème avec différents jeux de caractères, et la solution préférée semble être d'utiliser l' --iconvoption:

Vous pouvez utiliser l'option --iconv de rsync pour convertir entre UTF-8 NFC et NFD, au moins si vous êtes sur un Mac. Il existe un jeu de caractères spécial utf-8-mac qui signifie UTF-8 NFD. Donc, pour copier des fichiers de votre Mac vers votre NAS, vous devez exécuter quelque chose comme:

rsync -a --iconv=utf-8-mac,utf-8 localdir/ mynas:remotedir/

Cela convertira tous les noms de fichiers locaux de UTF-8 NFD en UTF-8 NFC sur le serveur distant. Le contenu des fichiers ne sera pas affecté.

Le problème est que cela ne fonctionne que dans un sens pour moi, à savoir lors de la synchronisation du Mac vers Linux. Mais je veux «aller dans l'autre sens», c'est-à-dire synchroniser DE la machine Linux vers le Mac. Et je veux initialiser l'opération à partir de mon Mac local. Mais quand j'essaye:

rsync -av --delete --iconv=utf-8,utf-8-mac mynas:remotedir/ localdir/

Je reçois une erreur:

iconv_open("UTF-8", "utf-8-mac") failed
rsync error: requested action not supported (code 4) at rsync.c(118) [sender=3.0.9]
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]

Je ne comprends pas pourquoi cela ne fonctionne pas. Ma version rsync sur Mac est mise à jour à partir de 2.6.9. à 3.1.1. en utilisant Macports . Notez que l'opération fonctionne alors lorsque je (sur le Mac, nota bene) lance une rsync du Mac vers Linux:

rsync -av --delete --iconv=utf-8-mac,utf-8 localdir/ mynas:remotedir/

Mais aller dans l'autre sens »à partir du mac - c'est ce que je veux faire - ne fonctionne pas.

Curieusement, les tests pour lancer la synchronisation à partir de la machine Linux rendent ce message étrange:

rsync: on remote machine: --iconv=UTF-8-MAC: unknown option
rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-45/rsync/main.c(1333) [server=2.6.9]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

y compris, notez, la déclaration très étrange [server=2.6.9], bien que j'ai mis à jour la 3.1.1 sur Mac. Pour certaines raisons, il semble que ma machine Linux ne «voit» que la version rsync d'origine sur le Mac.

Une suggestion sur la façon de résoudre ce problème?

MISE À JOUR 23 octobre : L'excellente suggestion de @Lee Johnson (voir ci-dessous), lancer la synchronisation à partir du serveur Linux fonctionne maintenant. Pour être complet, j'ai maintenant essayé toutes les combinaisons, et un motif intéressant émerge:

SUR MAC:

TRAVAUX: fichiers de Mac à Linux

ÉCHEC: fichiers de Linux vers Mac

SUR LINUX

TRAVAUX: fichiers de Linux à Mac

ÉCHEC: fichiers de Mac à Linux

En d'autres termes, l' --iconvoption ne semble fonctionner que dans un sens, avec des fichiers de la machine locale vers la télécommande, et non l'inverse. Cela ressemble à un bug pour moi, mais c'est peut-être la façon dont il est censé fonctionner?

Quelqu'un peut-il partager la lumière à ce sujet?

— Nick le Suédois
source

lors de l'utilisation d'un custom rsync(par exemple depuis homebrew) sur le mac et l'appeler depuis linux, il est nécessaire de spécifier le chemin correct en utilisant--rsync-path="/usr/local/bin/rsync"

— meduz

J'excluais .DS_Storede synchronisations et de ce Mac OS X ne pouvait pas les répertoires avec suppression de ces fichiers à l' intérieur. J'ai configuré les jeux de caractères avec --iconv, le chemin rsync sur le mac avec --rsync-path(j'utilise homebrew), puis j'ai dû ajouter --delete-excludedpour que les répertoires tenaces puissent être supprimés.

— Daniel

Réponses:

Après beaucoup d'expérimentations, et en grande partie grâce aux suggestions utiles de @Lee Johnson, j'ai finalement trouvé la solution, qui me semble maintenant embarrassante. En grande partie à cause d'un commentaire que j'ai lu en recherchant le problème, je pensais que vous étiez censé spécifier le jeu de caractères dans l'ordre de transformation; mais il semble que ce ne soit pas la syntaxe correcte. On devrait plutôt

TOUJOURS utiliser --iconv=utf-8-mac,utf-8lors de l'initialisation du rsync à partir du mac et TOUJOURS utiliser --iconv=utf-8,utf-8-maclors de l'initialisation du rsync à partir de la machine linux, peu importe si je veux synchroniser des fichiers à partir du mac ou de la machine linux.

Ensuite, cela fonctionne comme par magie!

— Nick le Suédois
source

UTF8-MAC est un pseudo-jeu de caractères et n'est pas disponible en soi avec iconvlib sur un système Linux, même pas avec la dernière version 3.1.1 dans Ubuntu 14.04 LTS. Cela ne fonctionne pas si vous essayez de lancer la synchronisation sous Linux.

— Achim Lammerts

Avez-vous récemment effectué une mise à niveau vers OS X Yosemite? J'ai eu le même problème, avant de me souvenir que j'avais mis à jour / usr / bin / rsync avec la version 3.1. Lorsque je suis passé à Yosemite, cela a été remplacé par l'ancienne version 2.6.9.

Dans mon propre cas, j'ai résolu le problème sur le Mac en reliant ma rsync 3.1 dans / usr / bin:

sudo -s
cd /usr/bin
mv rsync rsync-2.6.9
ln -s /usr/local/bin/rsync .
exit

— Lee Johnson
source

Merci un million, cela résout le mystère de la raison pour laquelle j'ai obtenu ce 2.6.9. message. (Sur mon Mac, cependant, la version installée de Macport se trouve dans / opt / local / bin / rsync, mais changer le lien vers ce sport a fonctionné comme par magie.) Malheureusement, je veux initialiser la synchronisation à partir de ma machine MAC, donc cela n'aide que jusqu'à ce que je comprenne que ma machine Linux peut comprendre quoi faire. Alors, pourquoi cela ne fonctionne-t-il pas lorsqu'il est initialisé à partir de mon Mac? Autrement dit, les "rsync -av --delete --iconv = utf-8, utf-8-mac mynas: remotedir / localdir /"

— Nick The Swede

Permettez-moi également de dire que, malheureusement, ma réputation est trop faible pour pouvoir attribuer +1 à votre réponse utile, et comme elle ne fonctionne toujours pas comme je le souhaite, je ne peux pas la cocher comme résolue. Étoile d'or dans mon esprit, en tout cas (et je promets de revenir en arrière et de vous +1 dès que mon représentant dépassera les 15)!

— Nick The Swede

Êtes-vous en train de dire qu'il ne fonctionne toujours pas du côté OS X, même avec rsync 3.x en cours d'exécution? Je ne pense pas que cela --iconvsoit pris en charge dans 2.6.9; même si rsync expédie simplement l'option à l'hôte distant pour la gestion, il doit reconnaître l'option du côté OS X. Que which rsync; rsync --versionvous dit un terminal OS X?

— Lee Johnson

C'est correct. Comme vous pouvez le voir dans le message d'erreur (troisième citation grise dans la question), il reconnaît que j'utilise 3.1 sur le mac: [Receiver = 3.1.1], et prétend que l'action n'est pas prise en charge, bien que cela fonctionne évidemment du côté Linux, ainsi que lorsque je synchronise, depuis le Mac, les fichiers du mac vers le serveur linux. Mais depuis le mac, les fichiers de linux vers mac ne fonctionnent pas. Si étrange (à mes yeux noob au moins).

— Nick The Swede

Lorsque vous essayez cela sous Linux, que se passe-t-il si vous forcez le chemin exécutable avec quelque chose comme --rsync-path=/opt/local/bin/rsyncpour obtenir votre version 3.1.1 connue du côté Mac?

— Lee Johnson