Deutsch English Français Italiano |
<ia0VOW1Gntb-rQvLlTV4cJ5mSrk@jntp> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder8.news.weretis.net!pasdenom.info!from-devjntp Message-ID: <ia0VOW1Gntb-rQvLlTV4cJ5mSrk@jntp> JNTP-Route: news2.nemoweb.net JNTP-DataType: Article Subject: Re: rsync en milieu =?UTF-8?Q?h=C3=A9t=C3=A9rog=C3=A8ne?= References: <fantome.forums.tDeContes-BED480.00060817032022@news.free.fr> <62327059$0$3441$426a74cc@news.free.fr> <877d8txxn1.fsf@universite-de-strasbourg.fr.invalid> <ZJudvuYECwR-EQAYQmdfUcm7wFU@jntp> <fantome.forums.tDeContes-7A0705.15593117032022@news.free.fr> Newsgroups: fr.comp.os.unix JNTP-HashClient: _4LHKTR_nIMyM3Oh1yKG6fLIJeg JNTP-ThreadID: fantome.forums.tDeContes-BED480.00060817032022@news.free.fr JNTP-Uri: http://news2.nemoweb.net/?DataID=ia0VOW1Gntb-rQvLlTV4cJ5mSrk@jntp User-Agent: Nemo/0.999a JNTP-OriginServer: news2.nemoweb.net Date: Thu, 17 Mar 22 16:29:03 +0000 Organization: Nemoweb JNTP-Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Injection-Info: news2.nemoweb.net; posting-host="57a7697b711e1390e43e8d98aa87a8bb5a5fec17"; logging-data="2022-03-17T16:29:03Z/6715067"; posting-account="44@news2.nemoweb.net"; mail-complaints-to="newsmaster@news2.nemoweb.net" JNTP-ProtocolVersion: 0.21.1 JNTP-Server: PhpNemoServer/0.94.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-JNTP-JsonNewsGateway: 0.96 From: pehache <pehache.7@gmail.com> Bytes: 3472 Lines: 58 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. >> > 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 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 Il faudrait que je retrouve le contexte de mon double utf8-mac ! > 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 ? > 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à... >> > 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 ? En principe oui, c'était le but :) HFS+ était une surcouche bricolée par dessus HFS, qui datait du début des années 80. APFS a été concçu from scratch.