Sujet : Re: rsync en milieu hétérogène
De : fantome.forums.tDeContes (at) *nospam* free.fr.invalid (Thomas)
Groupes : fr.comp.os.unixDate : 19. Mar 2022, 17:28:38
Autres entêtes
Organisation : Guest of ProXad - France
Message-ID : <fantome.forums.tDeContes-5BFFE9.17283819032022@news.free.fr>
References : 1 2 3 4 5 6
User-Agent : MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
In article <
ia0VOW1Gntb-rQvLlTV4cJ5mSrk@jntp>,
pehache <
pehache.7@gmail.com> wrote:
Le 17/03/2022 à 15:59, Thomas a écrit :
je ne comprend pas une chose :
on a probablement besoin de faire cette conversion pour que les accents
s'affichent correctement sur l'autre machine,
mais puisque ça reste des chaines utf-8 valides, pourquoi est ce que ça
fait ces drôles d'erreurs ?
rsync compare les noms de fichiers, et pour se faire il faut que
l'encodage soit le même.
c'était pas logique si on considérait que les 2 étaient du utf-8,
mais je pense que j'ai compris ...
Bon, toujours est-il que rsync a une option --iconv qui semble régler le
problème :
https://odd.blog/2020/10/06/rsync-between-mac-and-linux/
suggère --iconv=utf-8,utf-8-mac ("utf-8-mac" ? mdr)
rsync: on remote machine: --iconv=utf-8-mac: unknown option
Mmhhhh bizarre...
j'ai vérifié le man rsync du mac : il ne connait pas l'option --iconv
(tu devrais pouvoir le vérifier avec le n° de version qu'il donne).
J'ai eu un cas similaire à gérer, et ce qui a marché pour moi c'était
--iconv=utf-8-mac,utf-8-mac
mettre un utf-8 tout court ne changeait rien, et je n'ai pas compris ce
que ça convertissait en mettant deux fois utf-8-mac !
iconv_open("UTF-8", "utf-8-mac") failed
En fait c'est logique, tu lui dis que les noms locaux sont en utf8-mac, ce
qui ne doit pas être possible sur du extfs
en fait c'est possible, mais là ça n'est pas le cas, donc de toutes
façons ça n'était pas bon.
bon, ça a l'air bien compliqué avec ces vieilles machines ...
est ce que qqn a une autre idée ?
Faire le rsync depuis le Mac plutôt que depuis le PC linux ?
ça ne marche pas.
après avoir fait différentes manipulations avec un petit répertoire
contenant des noms de fichier avec accents, je pense que j'ai compris
l'origine du pb :
en fait, cette #### de HFS+ est "case-preserving" pour ce qui concerne
purement la case, mais se comporte comme un "case-insensitive" avec les
accents !
cad que quand on écrit un accent de la manière qui ne lui plait pas, il
le modifie à la manière qui lui plait, pour l'enregistrer et le
resservir plus tard ...
alors que ext4 ne fait pas ça.
(pour le vérifier complètement, il faudrait que je puisse voir à
l'intérieur des noms de fichiers, un simple ls ne le permet pas
puisqu'il affiche les accents correctement.)
la conséquence, c'est que ce pb de comparaison de noms de fichiers est
posé à chaque fois qu'on déplace des fichiers de ext4 vers HFS+, mais
pas quand on les déplace de HFS+ vers ext4.
peu importe depuis quelle machine on pilote ça,
et ça explique pourquoi je n'ai jamais eu de pb depuis mon mac jusqu'à
maintenant
(en fait j'utilise des machines virtuelles avec ext4, mais je n'ai
jamais mis d'accents dessus, ça n'est pas un usage "domestique").
genre, remplacer les caractères non-ascii par %, pour que au moins le
rsync serveur n'ait rien à gérer ?
Quel rsync serveur ? A priori il n'y en a pas là...
ce que je comprend c'est que :
à travers ssh, il ne fait pas du sftp ou du sshfs,
mais il lance un rsync distant qu'il utilise comme un serveur, même s'il
le referme après l'opération.
-- RAPID maintainerhttp://savannah.nongnu.org/projects/rapid/