Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!212.27.60.64.MISMATCH!cleanfeed3-b.proxad.net!nnrp1-2.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: Thu, 17 Mar 2022 15:59:32 +0100 Message-ID: Lines: 82 Organization: Guest of ProXad - France NNTP-Posting-Date: 17 Mar 2022 15:59:33 CET NNTP-Posting-Host: 91.175.52.121 X-Trace: 1647529173 news-4.free.fr 13442 91.175.52.121:9050 X-Complaints-To: abuse@proxad.net Bytes: 4155 In article , pehache wrote: > Le 17/03/2022 à 00:53, Alain Ketterlin a écrit : > > Nicolas George writes: > > > >> Thomas , dans le message > >> , a écrit : > >>> Destination : par défaut sous Mac OS X, HFS+. > >> > >> Vérifie si les caractères accentués ont été mis sous une forme canonique > >> différente. Je crois me rappeler qu'Apple a décidé d'utiliser une forme > >> décomposée, 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 ? (ça n'est pas une erreur à l'écriture du fichier, seulement lors d'une certaine comparaison !) > >> parce que faire comme tout le monde ça leur arracherait la > >> gueule et pour embêter gratuitement les gens qui voudraient utiliser autre > >> chose que des Appleries. > > > > Dans mon souvenir, HFS+ n'est même pas "case-sensitive" (par défaut)... en ada, on appelle ça "case-preserving", cad que lui il se souvient de la case que t'as utilisé en créant le fichier, mais si toi tu ne t'en souviens pas il le retrouve. y compris si tu crée un nouveau fichier dont seule la case est différente (mais ça a l'avantage d'être compatible avec les FS "case-insensitive", quand on crée dessus) > > > > 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 rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-40/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(226) [sender=3.1.1] > > 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 rsync error: requested action not supported (code 4) at rsync.c(122) [sender=3.1.1] rsync error: received SIGUSR1 (code 19) at main.c(1434) [sender=3.1.1] bon, ça a l'air bien compliqué avec ces vieilles machines ... est ce que qqn a une autre idée ? genre, remplacer les caractères non-ascii par %, pour que au moins le rsync serveur n'ait rien à gérer ? > > > > P/S: Pour mémoire : "[HFS+ is] complete and utter crap." (Linus Torvalds) > > C'est pour ça qu'il a été remplacé il y a plusieurs années par APFS c'est mieux conçu ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/