Path: ...!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!cleanfeed3-b.proxad.net!nnrp2-1.free.fr!not-for-mail From: Thomas Newsgroups: fr.comp.os.unix Mail-Copies-To: nobody Subject: Re: rsync en milieu =?UTF-8?Q?h=C3=A9t=C3=A9rog=C3=A8ne?= References: <62327059$0$3441$426a74cc@news.free.fr> <877d8txxn1.fsf@universite-de-strasbourg.fr.invalid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Sat, 19 Mar 2022 17:28:38 +0100 Message-ID: Lines: 102 Organization: Guest of ProXad - France NNTP-Posting-Date: 19 Mar 2022 17:28:39 CET NNTP-Posting-Host: 91.175.52.121 X-Trace: 1647707319 news-2.free.fr 29486 91.175.52.121:7284 X-Complaints-To: abuse@proxad.net Bytes: 4736 In article , pehache 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 maintainer http://savannah.nongnu.org/projects/rapid/