l'option '--delete-after' m'efface tous les fichiers dont le nom
contient des caractères non-ascii, aussitÍ´t après les avoir copiés.
il est probable que le pb soit lié au fait que rsync soit utilisé en
milieu hétérogène (mais je pensais que rsync était rodé Í ce genre de
cas de figure un peu biscornu) :
systèmes de fichiers :
Source : par défaut sous Ubuntu, je crois bien que c'est ext4.
Destination : par défaut sous Mac OS X, HFS+.
Vu la proportion de clients Apple qui doivent utiliser rsync en direct, cette motivation me parait peu probable.
Je n'ai pas suggéré qu'Apple avait fait ce changement précis pour enquiquiner sur ce cas précis.
Ca y ressemble quand même : "Je crois me rappeler qu'Apple a décidé d'utiliser une formedécomposée, parce que faire comme tout le monde ça leur arracherait lagueule et pour embêter gratuitement les gens qui voudraient utiliser autrechose que des Appleries."
Ce qui est vrai, c'est qu'Apple a la politique générale de ne jamais faire comme tout le monde
C'est assez vrai, il ont parfois le syndrÍ´me NIH (Not Invented Here)
pour enquiquiner les potentiels traͮtres dans tous les cas.
Dans certains cas c'est sÍ»rement vrai, mais en faire une grille de lecture systématique c'est une interprétation abusive.
Le 17/03/2022 Í 14:47, Nicolas George a écrit :
pehache , dans le message <5rcY_IgRAIkSKR4HTIxdrE41uaU@jntp>, a écrit :
Vu la proportion de clients Apple qui doivent utiliser rsync en direct,
cette motivation me parait peu probable.
Je n'ai pas suggéré qu'Apple avait fait ce changement précis pour
enquiquiner sur ce cas précis.
Ca y ressemble quand même : "Je crois me rappeler qu'Apple a décidé
d'utiliser une formedécomposée, parce que faire comme tout le monde ça
leur arracherait lagueule et pour embêter gratuitement les gens qui
voudraient utiliser autrechose que des Appleries."
Ce qui est vrai, c'est qu'Apple a la
politique générale de ne jamais faire comme tout le monde
C'est assez vrai, il ont parfois le syndrÍ´me NIH (Not Invented Here)
pour enquiquiner
les potentiels traͮtres dans tous les cas.
Dans certains cas c'est sͻrement vrai, mais en faire une grille de
lecture systématique c'est une interprétation abusive.
Vu la proportion de clients Apple qui doivent utiliser rsync en direct, cette motivation me parait peu probable.
Je n'ai pas suggéré qu'Apple avait fait ce changement précis pour enquiquiner sur ce cas précis.
Ca y ressemble quand même : "Je crois me rappeler qu'Apple a décidé d'utiliser une formedécomposée, parce que faire comme tout le monde ça leur arracherait lagueule et pour embêter gratuitement les gens qui voudraient utiliser autrechose que des Appleries."
Ce qui est vrai, c'est qu'Apple a la politique générale de ne jamais faire comme tout le monde
C'est assez vrai, il ont parfois le syndrÍ´me NIH (Not Invented Here)
pour enquiquiner les potentiels traͮtres dans tous les cas.
Dans certains cas c'est sÍ»rement vrai, mais en faire une grille de lecture systématique c'est une interprétation abusive.
pehache
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.
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.
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.
pehache
Le 17/03/2022 Í 17:29, pehache a écrit :
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 !
Alors c'est un rsync qui tourne sur le Mac, et qui fait ça (j'élague les options) : rsync --archive --delete /mnt/nfs/TOTO/* /Volumes/TITI TOTO est un montage NFS sur un NAS Synology (variante BSD), avec cette ligne dans /etc/auto_nfs : TOTO -fstype=nfs,noatime,rw,nfc nfs://xxxxx:/volume1/TOTO L'option nfc est nécessaire pour dire que sur le disque distant les noms de fichiers sont sous forme NFC, et je suppose qu'ils sont présentés sous forme NFD Í macOS. /Volumes/TITI est un disque externe formaté en exfat. Sans iconv du tout, la commande rsync ci-dessus a le même défaut que ce que tu as soulevé : les fichiers avec des caractères spéciaux dans le nom sont systématiquement effacés et recopiés. Pour que ça se comporte comme attendu je dois mettre : --iconv=utf-8,utf-8-mac ou --iconv=utf-8-mac,utf-8-mac 1) je ne comprends pas pourquoi ça marche pareil en mettant utf-8 ou utf-8-mac en première position. 2) le man dit que c'est --iconv=LOCAL,REMOTE ... sauf que dans le cas d'un rsync entre des disques locaux et/ou montés (pas de ssh ou démon rsync, donc pas de notion de machine distante), ce qui est de l'ordre du LOCAL et du REMOTE n'est pas clair du tout... 3) je comprends encore moins pourquoi ça marche alors que l'encodage sur exfat est de l'UTF-16 et pas de l'UTF-8 (ça je viens de le percuter en écrivant ce message !) Bref... -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine ST passe le mur du çon :
Le 17/03/2022 Í 17:29, pehache a écrit :
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 !
Alors c'est un rsync qui tourne sur le Mac, et qui fait ça (j'élague les
options) :
TOTO est un montage NFS sur un NAS Synology (variante BSD), avec cette
ligne dans /etc/auto_nfs :
TOTO -fstype=nfs,noatime,rw,nfc nfs://xxxxx:/volume1/TOTO
L'option nfc est nécessaire pour dire que sur le disque distant les noms
de fichiers sont sous forme NFC, et je suppose qu'ils sont présentés
sous forme NFD Í macOS.
/Volumes/TITI est un disque externe formaté en exfat.
Sans iconv du tout, la commande rsync ci-dessus a le même défaut que ce
que tu as soulevé : les fichiers avec des caractères spéciaux dans le
nom sont systématiquement effacés et recopiés. Pour que ça se comporte
comme attendu je dois mettre :
--iconv=utf-8,utf-8-mac
ou
--iconv=utf-8-mac,utf-8-mac
1) je ne comprends pas pourquoi ça marche pareil en mettant utf-8 ou
utf-8-mac en première position.
2) le man dit que c'est --iconv=LOCAL,REMOTE ... sauf que dans le cas
d'un rsync entre des disques locaux et/ou montés (pas de ssh ou démon
rsync, donc pas de notion de machine distante), ce qui est de l'ordre du
LOCAL et du REMOTE n'est pas clair du tout...
3) je comprends encore moins pourquoi ça marche alors que l'encodage sur
exfat est de l'UTF-16 et pas de l'UTF-8 (ça je viens de le percuter en
écrivant ce message !)
Bref...
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>
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 !
Alors c'est un rsync qui tourne sur le Mac, et qui fait ça (j'élague les options) : rsync --archive --delete /mnt/nfs/TOTO/* /Volumes/TITI TOTO est un montage NFS sur un NAS Synology (variante BSD), avec cette ligne dans /etc/auto_nfs : TOTO -fstype=nfs,noatime,rw,nfc nfs://xxxxx:/volume1/TOTO L'option nfc est nécessaire pour dire que sur le disque distant les noms de fichiers sont sous forme NFC, et je suppose qu'ils sont présentés sous forme NFD Í macOS. /Volumes/TITI est un disque externe formaté en exfat. Sans iconv du tout, la commande rsync ci-dessus a le même défaut que ce que tu as soulevé : les fichiers avec des caractères spéciaux dans le nom sont systématiquement effacés et recopiés. Pour que ça se comporte comme attendu je dois mettre : --iconv=utf-8,utf-8-mac ou --iconv=utf-8-mac,utf-8-mac 1) je ne comprends pas pourquoi ça marche pareil en mettant utf-8 ou utf-8-mac en première position. 2) le man dit que c'est --iconv=LOCAL,REMOTE ... sauf que dans le cas d'un rsync entre des disques locaux et/ou montés (pas de ssh ou démon rsync, donc pas de notion de machine distante), ce qui est de l'ordre du LOCAL et du REMOTE n'est pas clair du tout... 3) je comprends encore moins pourquoi ça marche alors que l'encodage sur exfat est de l'UTF-16 et pas de l'UTF-8 (ça je viens de le percuter en écrivant ce message !) Bref... -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine ST passe le mur du çon :
Thomas
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/
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.
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/
pehache
Le 19/03/2022 Í 17:28, Thomas a écrit :
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).
En effet sur mon macOS (10.12, donc qui date de quelques années) c'est une version de rsync relativement ancienne qui est dispo, et j'avais oublié que j'avais installé le rsync de MacPorts, qui lui supporte l'option.
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 ...
??
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.
Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner même en l'absence d'un rsync disponible sur la machine distante. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine ST passe le mur du çon :
Le 19/03/2022 Í 17:28, Thomas a écrit :
Bon, toujours est-il que rsync a une option --iconv qui semble régler le
problème :
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).
En effet sur mon macOS (10.12, donc qui date de quelques années) c'est
une version de rsync relativement ancienne qui est dispo, et j'avais
oublié que j'avais installé le rsync de MacPorts, qui lui supporte l'option.
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 ...
??
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.
Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner
même en l'absence d'un rsync disponible sur la machine distante.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>
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).
En effet sur mon macOS (10.12, donc qui date de quelques années) c'est une version de rsync relativement ancienne qui est dispo, et j'avais oublié que j'avais installé le rsync de MacPorts, qui lui supporte l'option.
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 ...
??
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.
Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner même en l'absence d'un rsync disponible sur la machine distante. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine ST passe le mur du çon :
Nicolas George
pehache , dans le message , a écrit :
Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner même en l'absence d'un rsync disponible sur la machine distante.
???
pehache , dans le message <j9ov2hF20dpU1@mid.individual.net>, a écrit :
Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner
même en l'absence d'un rsync disponible sur la machine distante.
Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner même en l'absence d'un rsync disponible sur la machine distante.
???
Nicolas George
Thomas , dans le message , a écrit :
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 ...
Exactement. «Â Gloire Í Apple ! Merci notre maÍ®tre de nous préserver de la tentation d'aller voir ailleurs si l'herbe est plus grasse. »
Thomas , dans le message
<fantome.forums.tDeContes-5BFFE9.17283819032022@news.free.fr>, a écrit :
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 ...
Exactement. «Â Gloire Í Apple ! Merci notre maÍ®tre de nous préserver de la
tentation d'aller voir ailleurs si l'herbe est plus grasse. »
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 ...
Exactement. «Â Gloire Í Apple ! Merci notre maÍ®tre de nous préserver de la tentation d'aller voir ailleurs si l'herbe est plus grasse. »
pehache
Le 20/03/2022 Í 16:40, Nicolas George a écrit :
pehache , dans le message , a écrit :
Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner même en l'absence d'un rsync disponible sur la machine distante.
???
J'avais lu ça je ne sais plus o͹, mais effet c'est faux. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine ST passe le mur du çon :
Le 20/03/2022 Í 16:40, Nicolas George a écrit :
pehache , dans le message <j9ov2hF20dpU1@mid.individual.net>, a écrit :
Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner
même en l'absence d'un rsync disponible sur la machine distante.
???
J'avais lu ça je ne sais plus o͹, mais effet c'est faux.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>
Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner même en l'absence d'un rsync disponible sur la machine distante.
???
J'avais lu ça je ne sais plus o͹, mais effet c'est faux. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine ST passe le mur du çon :
pehache
Le 20/03/2022 Í 16:42, Nicolas George a écrit :
Thomas , dans le message , a écrit :
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 ...
Exactement. «Â Gloire Í Apple ! Merci notre maÍ®tre de nous préserver de la tentation d'aller voir ailleurs si l'herbe est plus grasse. »
T'es lourd avec ça... Mais t'as raison, en 1998 Apple a décidé d'emmerder sciemment ses 0,001% de clients qui utiliseraient peut-être rsync entre un Mac et PC Linux dans le futur. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine ST passe le mur du çon :
Le 20/03/2022 Í 16:42, Nicolas George a écrit :
Thomas , dans le message
<fantome.forums.tDeContes-5BFFE9.17283819032022@news.free.fr>, a écrit :
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 ...
Exactement. «Â Gloire Í Apple ! Merci notre maÍ®tre de nous préserver de la
tentation d'aller voir ailleurs si l'herbe est plus grasse. »
T'es lourd avec ça... Mais t'as raison, en 1998 Apple a décidé
d'emmerder sciemment ses 0,001% de clients qui utiliseraient peut-être
rsync entre un Mac et PC Linux dans le futur.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>
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 ...
Exactement. «Â Gloire Í Apple ! Merci notre maÍ®tre de nous préserver de la tentation d'aller voir ailleurs si l'herbe est plus grasse. »
T'es lourd avec ça... Mais t'as raison, en 1998 Apple a décidé d'emmerder sciemment ses 0,001% de clients qui utiliseraient peut-être rsync entre un Mac et PC Linux dans le futur. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine ST passe le mur du çon :
Nicolas George
pehache , dans le message , a écrit :
T'es lourd avec ça...
Et toi t'es lourd Í répondre pour défendre l'indéfendable.
pehache , dans le message <j9qpmiFcinqU1@mid.individual.net>, a écrit :
T'es lourd avec ça...
Et toi t'es lourd Í répondre pour défendre l'indéfendable.
