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+.
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, 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.
Thomas , dans le message
<fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, 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, 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.
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, 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.
Alain Ketterlin
Nicolas George <nicolas$ 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, 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)... 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) -- Alain. P/S: Pour mémoire : "[HFS+ is] complete and utter crap." (Linus Torvalds)
Nicolas George <nicolas$george@salle-s.org> writes:
Thomas , dans le message
<fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, 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, 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)...
Bon, toujours est-il que rsync a une option --iconv qui semble régler le
problème :
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, 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)... 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) -- Alain. P/S: Pour mémoire : "[HFS+ is] complete and utter crap." (Linus Torvalds)
pehache
Le 17/03/2022 Í 00:06, Thomas a écrit :
bonjour :-) j'ai un pb avec rsync : 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+.
Le rsync est lancé cÍ´té Ubuntu ou cÍ´té Mac ? Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une connexion SSH ?
Le 17/03/2022 Í 00:06, Thomas a écrit :
bonjour :-)
j'ai un pb avec rsync :
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+.
Le rsync est lancé cÍ´té Ubuntu ou cÍ´té Mac ?
Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une
connexion SSH ?
bonjour :-) j'ai un pb avec rsync : 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+.
Le rsync est lancé cÍ´té Ubuntu ou cÍ´té Mac ? Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une connexion SSH ?
pehache
Le 17/03/2022 Í 00:18, Nicolas George a écrit :
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, 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.
Vu la proportion de clients Apple qui doivent utiliser rsync en direct, cette motivation me parait peu probable.
Le 17/03/2022 Í 00:18, Nicolas George a écrit :
Thomas , dans le message
<fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, 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, 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.
Vu la proportion de clients Apple qui doivent utiliser rsync en direct,
cette motivation me parait peu probable.
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, 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.
Vu la proportion de clients Apple qui doivent utiliser rsync en direct, cette motivation me parait peu probable.
pehache
Le 17/03/2022 Í 00:53, Alain Ketterlin a écrit :
Nicolas George <nicolas$ 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, 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)... 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)
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 !
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
Le 17/03/2022 Í 00:53, Alain Ketterlin a écrit :
Nicolas George <nicolas$george@salle-s.org> writes:
Thomas , dans le message
<fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, 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, 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)...
Bon, toujours est-il que rsync a une option --iconv qui semble régler le
problème :
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, 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)... 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)
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 !
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
Nicolas George
pehache , dans le message , 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. Ce qui est vrai, c'est qu'Apple a la politique générale de ne jamais faire comme tout le monde pour enquiquiner les potentiels traÍ®tres dans tous les cas.
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. Ce qui est vrai, c'est qu'Apple a la
politique générale de ne jamais faire comme tout le monde pour enquiquiner
les potentiels traͮtres dans tous les cas.
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. Ce qui est vrai, c'est qu'Apple a la politique générale de ne jamais faire comme tout le monde pour enquiquiner les potentiels traÍ®tres dans tous les cas.
Thomas
In article , pehache wrote:
Le 17/03/2022 Í 00:06, Thomas a écrit :
bonjour :-) j'ai un pb avec rsync : 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+.
Le rsync est lancé cÍ´té Ubuntu ou cÍ´té Mac ?
Ubuntu en fait je le fais aussi en sens inverse (pas avec le meme mac) mais je n'ai remarqué aucun pb !
Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une connexion SSH ?
toujours avec ssh géré par rsync directement. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <HExjKI8TLTRVz27SV3zGhvIfSFk@jntp>,
pehache <pehache.7@gmail.com> wrote:
Le 17/03/2022 Í 00:06, Thomas a écrit :
> bonjour :-)
>
>
> j'ai un pb avec rsync :
>
> 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+.
Le rsync est lancé cÍ´té Ubuntu ou cÍ´té Mac ?
Ubuntu
en fait je le fais aussi en sens inverse (pas avec le meme mac) mais je
n'ai remarqué aucun pb !
Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une
connexion SSH ?
bonjour :-) j'ai un pb avec rsync : 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+.
Le rsync est lancé cÍ´té Ubuntu ou cÍ´té Mac ?
Ubuntu en fait je le fais aussi en sens inverse (pas avec le meme mac) mais je n'ai remarqué aucun pb !
Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une connexion SSH ?
toujours avec ssh géré par rsync directement. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
Thomas
In article <62333bf1$0$24261$, Nicolas George <nicolas$ wrote:
pehache , dans le message , 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. Ce qui est vrai, c'est qu'Apple a la politique générale de ne jamais faire comme tout le monde pour enquiquiner les potentiels traÍ®tres dans tous les cas.
et c'est bien pour ça (en partie) que j'ai décidé de prendre la tangente ! le pb, c'est qu'une période de transition est nécessaire ... -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <62333bf1$0$24261$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:
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. Ce qui est vrai, c'est qu'Apple a la
politique générale de ne jamais faire comme tout le monde pour enquiquiner
les potentiels traͮtres dans tous les cas.
et c'est bien pour ça (en partie) que j'ai décidé de prendre la
tangente !
le pb, c'est qu'une période de transition est nécessaire ...
In article <62333bf1$0$24261$, Nicolas George <nicolas$ wrote:
pehache , dans le message , 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. Ce qui est vrai, c'est qu'Apple a la politique générale de ne jamais faire comme tout le monde pour enquiquiner les potentiels traÍ®tres dans tous les cas.
et c'est bien pour ça (en partie) que j'ai décidé de prendre la tangente ! le pb, c'est qu'une période de transition est nécessaire ... -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
pehache
Le 17/03/2022 Í 15:12, Thomas a écrit :
Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une connexion SSH ?
toujours avec ssh géré par rsync directement.
OK donc c'est différent du cas que j'avais rencontré, o͹ c'était par un montage NFS, sachant que le montage NFS lui-même gère (ou pas, suivant les options) la différence d'encodage des caractères.
Le 17/03/2022 Í 15:12, Thomas a écrit :
Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une
connexion SSH ?
toujours avec ssh géré par rsync directement.
OK donc c'est différent du cas que j'avais rencontré, o͹ c'était par
un montage NFS, sachant que le montage NFS lui-même gère (ou pas,
suivant les options) la différence d'encodage des caractères.
Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une connexion SSH ?
toujours avec ssh géré par rsync directement.
OK donc c'est différent du cas que j'avais rencontré, o͹ c'était par un montage NFS, sachant que le montage NFS lui-même gère (ou pas, suivant les options) la différence d'encodage des caractères.
Thomas
In article , pehache wrote:
Le 17/03/2022 Í 00:53, Alain Ketterlin a écrit :
Nicolas George <nicolas$ 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/
In article <ZJudvuYECwR-EQAYQmdfUcm7wFU@jntp>,
pehache <pehache.7@gmail.com> wrote:
Le 17/03/2022 Í 00:53, Alain Ketterlin a écrit :
> Nicolas George <nicolas$george@salle-s.org> writes:
>
>> Thomas , dans le message
>> <fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, 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
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/
