montage NFS, encodage des noms de fichiers, et rsync
Le
pehache
(léger xpost sans fu2)
Bonjour,
Sur un Mac sous 10.12 j'ai un montage NFS d'un dossier partagé sur un
NAS Synology (qui tourne sous un Linux). Pour ça j'utilise automount
avec une entrée dans le fichier /etc/auto_nfs :
Programs -fstype=nfs,noatime,rw,nfc nfs://synonas:/volume1/Programs
D'après le man de mount_nfs, l'option "nfc" sert à convertir l'encodage
des caractères des noms des fichiers : macOS et Linux utilisent tous
deux UTF8, mais il y a deux variantes qui notamment encodent
différemment les caractères accentués: NFD (macOS) et NFC (Linux). Bien
Maintenant je fais un rsync sur le Mac pour synchroniser des fichiers du
serveur vers le Mac. Quelque chose comme :
$ rsync -av --delete /mnt/nfs/Programs/SOURCE/ ./DESTINATION
Ca marche, sauf que les fichiers comportant des caractères accentués
dans les noms sont systématiquement recopiés, même quand ils n'ont pas
été modifiés entre deux rsync. Les fichiers dont les noms ne comportent
pas de caractères spéciaux ne sont eux recopiés que s'ils ont été
modifiés, comme prévu.
En cherchant un peu je vois que l'option --iconv de rsync permet de
gérer les encodages différents :
--iconv=LOCAL,REMOTE
LOCAL étant l'encodage sur la machine où rsync tourne, REMOTE étant
l'encodage sur le serveur distant.
Déjà, la version de rsync par défaut sous macOS 10.12 est trop vieille
et n'a pas l'option --iconv, j'ai donc installé le rsync fourni par
MacPorts, plus récent.
Depuis un Mac vers un serveur Linux, il est conseillé un peu partout sur
le web de mettre :
--iconv=utf-8-mac,utf-8
utf-8 correspond à la variante NFC d'UFT8, utf-8-mac à la variante NFD
Sauf que dans mon cas ça ne change rien, les fichiers avec accents sont
toujours recopiés à chaque fois. En tâtonnant je trouve que ce qui
marche c'est l'un des deux :
--iconv=utf-8,utf-8-mac
--iconv=utf-8-mac,utf-8-mac
Problème résolu, les fichiers ne sont plus recopiés pour rien,
MAIS JE NE COMPRENDS RIEN DE CE QUI SE PASSE !
1) Déjà, pourquoi y a-t-il besoin du --iconv, alors que l'option "nfc"
du montage NFS est justement là pour faire les conversions nécessaires
et présenter à macOS les fichiers du serveur comme s'il étaient en UT8-NFD ?
2) la solution --iconv=utf-8,utf-8-mac dit que l'encodage local est du
UTF8-NFC, alors que la réalité c'est du UTF8-NFD : une explication ?
3) la solution --iconv=utf-8-mac,utf-8-mac est censée ne rien convertir
en définitive Donc pourquoi elle ne se comporte pas pareil que sans
--iconv du tout ??
Si quelqu'un veut bien m'éclairer
--
"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
Bonjour,
Sur un Mac sous 10.12 j'ai un montage NFS d'un dossier partagé sur un
NAS Synology (qui tourne sous un Linux). Pour ça j'utilise automount
avec une entrée dans le fichier /etc/auto_nfs :
Programs -fstype=nfs,noatime,rw,nfc nfs://synonas:/volume1/Programs
D'après le man de mount_nfs, l'option "nfc" sert à convertir l'encodage
des caractères des noms des fichiers : macOS et Linux utilisent tous
deux UTF8, mais il y a deux variantes qui notamment encodent
différemment les caractères accentués: NFD (macOS) et NFC (Linux). Bien
Maintenant je fais un rsync sur le Mac pour synchroniser des fichiers du
serveur vers le Mac. Quelque chose comme :
$ rsync -av --delete /mnt/nfs/Programs/SOURCE/ ./DESTINATION
Ca marche, sauf que les fichiers comportant des caractères accentués
dans les noms sont systématiquement recopiés, même quand ils n'ont pas
été modifiés entre deux rsync. Les fichiers dont les noms ne comportent
pas de caractères spéciaux ne sont eux recopiés que s'ils ont été
modifiés, comme prévu.
En cherchant un peu je vois que l'option --iconv de rsync permet de
gérer les encodages différents :
--iconv=LOCAL,REMOTE
LOCAL étant l'encodage sur la machine où rsync tourne, REMOTE étant
l'encodage sur le serveur distant.
Déjà, la version de rsync par défaut sous macOS 10.12 est trop vieille
et n'a pas l'option --iconv, j'ai donc installé le rsync fourni par
MacPorts, plus récent.
Depuis un Mac vers un serveur Linux, il est conseillé un peu partout sur
le web de mettre :
--iconv=utf-8-mac,utf-8
utf-8 correspond à la variante NFC d'UFT8, utf-8-mac à la variante NFD
Sauf que dans mon cas ça ne change rien, les fichiers avec accents sont
toujours recopiés à chaque fois. En tâtonnant je trouve que ce qui
marche c'est l'un des deux :
--iconv=utf-8,utf-8-mac
--iconv=utf-8-mac,utf-8-mac
Problème résolu, les fichiers ne sont plus recopiés pour rien,
MAIS JE NE COMPRENDS RIEN DE CE QUI SE PASSE !
1) Déjà, pourquoi y a-t-il besoin du --iconv, alors que l'option "nfc"
du montage NFS est justement là pour faire les conversions nécessaires
et présenter à macOS les fichiers du serveur comme s'il étaient en UT8-NFD ?
2) la solution --iconv=utf-8,utf-8-mac dit que l'encodage local est du
UTF8-NFC, alors que la réalité c'est du UTF8-NFD : une explication ?
3) la solution --iconv=utf-8-mac,utf-8-mac est censée ne rien convertir
en définitive Donc pourquoi elle ne se comporte pas pareil que sans
--iconv du tout ??
Si quelqu'un veut bien m'éclairer
--
"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
In fr.comp.os.linux.configuration pehache
NFC et NFD ne sont pas des encodages proprement dit, les deux sont
encodables p.ex. en UTF-8. Ce sont des représentations plus
ou moins longue d'un symbole, soit sous forme c)ompacte (NFC,
un seul point de code UNICODE pour é), soit sous forme d)écomposée
(NFD, soit avec deux points de code UNICODE pour é: un symbole
ASCII e (page 0, bloc 0) et un symbole de composition "ajoute un '").
Ensuite c'est converti en 2 octets UTF-8 (pour des caractères de la
page 0 bloc 1, aka anciennement latin-1) pour NFC, et en au moins
deux fois 2 pour la forme NFD.
Une vieille règle de télécom (plus toujours appréciée aujourd'hui)
est: sois permissif dans ce que tu acceptes, et très restrictif
dans ce que tu envoies.
Donc, un convertisseur vers NFC devrait accepter à la fois
du NFD et du NFC en entrée et tout passer en NFC; symétriquement,
un convertisseur vers NFD devrait accepter du NFC et du NFD
en entrée, mais ne produire que du NFD en sortie.
J'aurais envie de dire que le format le plus interopérable
est NFC, donc que lorsqu'on parle sur le réseau on devrait
travailler en NFC, mais je n'ai rien pour soutenir cette
affirmation. Cela n'empêche pas, pour respecter la vieille
règle, de tout convertir en NFC en entrée quand même.
J'interprète ceci ainsi, mais j'ai peut-être tort:
quoi que tu reçoives (NFC ou NFD), convertis en NFD.
A nouveau, convertis tout en NFD, et si c'est déjà du
NFD ne change rien.
Elle doit être permissive dans ce qu'elle reçoit :)
Pour un é, ce serait 1+2, pas 2+2.
Ce qui ici se traduit par : si tu utilises autre chose que a-zA-Z0-9_.-
dans tes noms de fichiers, tu cherches les coups.
NFC est plus proche de l'hypothèse, fausse mais répandue, qu'un
caractère correspond toujours à un codepoint. Mais la raison, c'est
surtout qu'à peu près tout le monde utilise NFC, tout simplement. Sauf
Apple, qui a probablement des raisons techniques à avancer, mais ces
raisons techniques sont dérisoires et la vraie raison, c'est de ne pas
faire comme tout le monde pour compliquer la tâche de ceux qui veulent
partir, comme d'habitude.
OK
Oui, peut-être (voire probablement). Ce qui pose quand même deux
questions :
- comment iconv sait-il ce qu'il reçoit ? Il n'y a aucune ambigüité
possible entre NFC et NFD ?
- la notion de LOCAL et REMOTE dans le man est peu claire, et en fait LOCAL
serait à interpréter comme concernant la source, et REMOTE la destination
?
OK...
C'est tout à fait normal.
Ceux qui sont fidèles à cette firme, qui produit de l'équipement
supérieur pour les clients supérieurs, ont tout intérêt à comprendre
que l'apostasie est à déconseiller !
--
Jean-Pierre Kuypers
Veuillez avancer les phrases dans leur con-
texte avant de partir sciemment.
Merci de confirmer que (1) l'attachement à Apple relève de la religion
et (2) la prétendue supériorité de l'équipement n'est pas suffisante
pour retenir les utilisateurs.
Les macounets aiment bien se tirer une balle dans le pied, mais
seulement si la balle est plaquée-or.
En général c'est ce que je fais, mais parfois on ne choisit pas.
Sur ce point précis j'en doute. Je n'ai jamais eu de surprise avec les
noms de fichiers en les faisant passer entre macOS, Windows, et Linux, que
ce soit par des disques externes ou par des montages SMB. Ce n'est qu'avec
rsync sur le montage NFS que le problème s'est manifesté à ce jour chez
moi, ce qui correspond à mon avis à un usage extrêmement marginal parmi
les utilisateurs de Mac.
La raison est peut-être tout simplement qu'à l'époque où ils ont fait
ce choix il n'y avait pas un usage bien établi d'une méthode plutôt que
l'autre.
Je crois qu'il y avait des morceaux de deuxième degré dans la réponse de
JPK...
Habitude des maqueux dès le début.
Aussi des suites bureautiques (LibreOffice, MS-Office...) qui par défaut donne comme nom le début du texte.
Tiens, au fait, pourquoi à la création du profil utilisateur Ubuntu (et dérivés), je retrouve un dossier "~/Vidéos" ?
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Il faut dire que bon, tu donnes un nom qui veut dire quelque chose en
français, naturellement tu utilises des accents si tu n'as pas connu
l'informatique en ascii pur et dur...
Tu as tout à fait raison ! Quand je passe de macOS à Windows 10 via
Bootcamp, le changement est tel que j'abandonne toute idée d'apostasie.
Il n'est même pas nécessaire de faire appel à l'Inquisition.