montage NFS, encodage des noms de fichiers, et rsync
17 réponses
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
[ Followup-To: fr.comp.os.mac-os.x ] In fr.comp.os.linux.configuration pehache wrote:
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
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.
--iconv=utf-8,utf-8-mac
J'interprète ceci ainsi, mais j'ai peut-être tort: quoi que tu reçoives (NFC ou NFD), convertis en NFD.
--iconv=utf-8-mac,utf-8-mac
A nouveau, convertis tout en NFD, et si c'est déjà du NFD ne change rien.
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 ??
Elle doit être permissive dans ce qu'elle reçoit :)
[ Followup-To: fr.comp.os.mac-os.x ]
In fr.comp.os.linux.configuration pehache <pehache.7@gmail.com> wrote:
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
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.
--iconv=utf-8,utf-8-mac
J'interprète ceci ainsi, mais j'ai peut-être tort:
quoi que tu reçoives (NFC ou NFD), convertis en NFD.
--iconv=utf-8-mac,utf-8-mac
A nouveau, convertis tout en NFD, et si c'est déjà du
NFD ne change rien.
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 ??
Elle doit être permissive dans ce qu'elle reçoit :)
[ Followup-To: fr.comp.os.mac-os.x ] In fr.comp.os.linux.configuration pehache wrote:
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
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.
--iconv=utf-8,utf-8-mac
J'interprète ceci ainsi, mais j'ai peut-être tort: quoi que tu reçoives (NFC ou NFD), convertis en NFD.
--iconv=utf-8-mac,utf-8-mac
A nouveau, convertis tout en NFD, et si c'est déjà du NFD ne change rien.
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 ??
Elle doit être permissive dans ce qu'elle reçoit :)
Nicolas George
Marc SCHAEFER , dans le message <qagshr$nv3$, a écrit :
et en au moins deux fois 2 pour la forme NFD.
Pour un é, ce serait 1+2, pas 2+2.
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.
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.
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.
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.
Marc SCHAEFER , dans le message <qagshr$nv3$1@shakotay.alphanet.ch>, a
écrit :
et en au moins
deux fois 2 pour la forme NFD.
Pour un é, ce serait 1+2, pas 2+2.
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.
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.
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.
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.
Marc SCHAEFER , dans le message <qagshr$nv3$, a écrit :
et en au moins deux fois 2 pour la forme NFD.
Pour un é, ce serait 1+2, pas 2+2.
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.
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.
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.
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.
pehache
Le 03/05/2019 à 10:02, Marc SCHAEFER a écrit :
[ Followup-To: fr.comp.os.mac-os.x ] In fr.comp.os.linux.configuration pehache wrote:
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
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.
OK
--iconv=utf-8,utf-8-mac
J'interprète ceci ainsi, mais j'ai peut-être tort: quoi que tu reçoives (NFC ou NFD), convertis en NFD.
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 ?
--iconv=utf-8-mac,utf-8-mac
A nouveau, convertis tout en NFD, et si c'est déjà du NFD ne change rien.
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 ? ?
Elle doit être permissive dans ce qu'elle reçoit :)
OK...
Le 03/05/2019 à 10:02, Marc SCHAEFER a écrit :
[ Followup-To: fr.comp.os.mac-os.x ]
In fr.comp.os.linux.configuration pehache <pehache.7@gmail.com> wrote:
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
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.
OK
--iconv=utf-8,utf-8-mac
J'interprète ceci ainsi, mais j'ai peut-être tort:
quoi que tu reçoives (NFC ou NFD), convertis en NFD.
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
?
--iconv=utf-8-mac,utf-8-mac
A nouveau, convertis tout en NFD, et si c'est déjà du
NFD ne change rien.
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 ? ?
Elle doit être permissive dans ce qu'elle reçoit :)
[ Followup-To: fr.comp.os.mac-os.x ] In fr.comp.os.linux.configuration pehache wrote:
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
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.
OK
--iconv=utf-8,utf-8-mac
J'interprète ceci ainsi, mais j'ai peut-être tort: quoi que tu reçoives (NFC ou NFD), convertis en NFD.
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 ?
--iconv=utf-8-mac,utf-8-mac
A nouveau, convertis tout en NFD, et si c'est déjà du NFD ne change rien.
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 ? ?
Elle doit être permissive dans ce qu'elle reçoit :)
OK...
Jean-Pierre Kuypers
In article (Dans l'article) <5ccbfbab$0$31417$, Nicolas George <nicolas$ wrote (écrivait) :
... à 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.
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.
In article (Dans l'article) <5ccbfbab$0$31417$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote (écrivait) :
... à 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.
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.
In article (Dans l'article) <5ccbfbab$0$31417$, Nicolas George <nicolas$ wrote (écrivait) :
... à 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.
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.
Nicolas George
Jean-Pierre Kuypers , dans le message <030520191052403850%, a écrit :
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 !
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.
Jean-Pierre Kuypers , dans le message
<030520191052403850%Kuypers@address.invalid>, a écrit :
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 !
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.
Jean-Pierre Kuypers , dans le message <030520191052403850%, a écrit :
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 !
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.
pehache
Le 03/05/2019 à 10:28, Nicolas George a écrit :
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.
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.
En général c'est ce que je fais, mais parfois on ne choisit pas.
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.
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.
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.
Le 03/05/2019 à 10:28, Nicolas George a écrit :
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.
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.
En général c'est ce que je fais, mais parfois on ne choisit pas.
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.
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.
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.
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.
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.
En général c'est ce que je fais, mais parfois on ne choisit pas.
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.
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.
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.
pehache
Le 03/05/2019 à 11:09, Nicolas George a écrit :
Jean-Pierre Kuypers , dans le message <030520191052403850%, a écrit :
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 !
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.
Je crois qu'il y avait des morceaux de deuxième degré dans la réponse de JPK...
Le 03/05/2019 à 11:09, Nicolas George a écrit :
Jean-Pierre Kuypers , dans le message
<030520191052403850%Kuypers@address.invalid>, a écrit :
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 !
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.
Je crois qu'il y avait des morceaux de deuxième degré dans la réponse de
JPK...
Jean-Pierre Kuypers , dans le message <030520191052403850%, a écrit :
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 !
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.
Je crois qu'il y avait des morceaux de deuxième degré dans la réponse de JPK...
Sergio
Le 03/05/2019 à 10:28, Nicolas George a écrit :
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.
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
Le 03/05/2019 à 10:28, Nicolas George a écrit :
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.
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
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.
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
pehache
Le 03/05/2019 à 11:59, Sergio a écrit :
Le 03/05/2019 à 10:28, Nicolas George a écrit :
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.
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.
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...
Tiens, au fait, pourquoi à la création du profil utilisateur Ubuntu (et dérivés), je retrouve un dossier "~/Vidéos" ?
Le 03/05/2019 à 11:59, Sergio a écrit :
Le 03/05/2019 à 10:28, Nicolas George a écrit :
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.
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.
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...
Tiens, au fait, pourquoi à la création du profil utilisateur Ubuntu (et
dérivés), je retrouve un dossier "~/Vidéos" ?
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.
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.
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...
Tiens, au fait, pourquoi à la création du profil utilisateur Ubuntu (et dérivés), je retrouve un dossier "~/Vidéos" ?
Patrick
On 2019-05-03 08:52:40 +0000, Jean-Pierre Kuypers said:
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 !
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.
On 2019-05-03 08:52:40 +0000, Jean-Pierre Kuypers said:
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 !
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.
On 2019-05-03 08:52:40 +0000, Jean-Pierre Kuypers said:
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 !
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.
