Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

rsync en milieu hétérogène

21 réponses
Avatar
Thomas
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+.

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

10 réponses

1 2 3
Avatar
Nicolas George
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.
Avatar
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)
Avatar
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 ?
Avatar
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.
Avatar
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
Avatar
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.
Avatar
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/
Avatar
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/
Avatar
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.
Avatar
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/
1 2 3