<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Salut Frédéric,</p>
<p>J'ai également les directives "fruit" dans mon smb.conf. <br>
</p>
<p># Mac<br>
vfs objects = catia fruit streams_xattr<br>
fruit:metadata = netatalk<br>
fruit:model = MacSamba<br>
fruit:posix_rename = yes<br>
fruit:veto_appledouble = no<br>
fruit:resource = file<br>
fruit:wipe_intentionally_left_blank_rfork = yes<br>
fruit:delete_empty_adfiles = yes<br>
fruit:time machine = no<br>
fruit:encoding = native<br>
fruit:aapl = yes</p>
<p>Peut-être qu'une de ces directives doit être changée.<br>
</p>
<p>En soit, les fichiers Apple ajoutés d'ordinateurs Mac sont plus
ou moins bien gérés sur les PC Windows du parc, à part que si un
utilisateur Windows (ou Linux d'ailleurs) se mets à modifier ce
fichier, on se retrouve avec deux fois le même fichier
(visuellement) dans l'explorateur Windows, dans le même dossier,
ce qui est troublant... Sur le serveur Debian, on voit que l'un
des fichiers a des caractères accentués absurdes. De mémoire, le
Nextcloud n'arrivait pas à correctement gérer cette situation.</p>
<p>Là, mon cron passe convmv tous les soirs sur les partages samba
(il s'exécute assez rapidement) et il "corrige" les noms de
fichiers. Depuis, je n'ai plus de soucis avec Nextcloud. Ex. de la
sortie envoyée par courriel :</p>
<pre class="moz-quote-pre" wrap="">Ready! I converted 13 files in 69 seconds.</pre>
<p></p>
<p>Sur ~720Go de données.<br>
</p>
<p>a+</p>
<p>Samuel</p>
<div class="moz-cite-prefix">Le 20.04.24 à 10:56, Frederic Dumas via
gull a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:E3F85C38-3422-4120-8959-8E90AE1B87A7@ellis.siteparc.fr">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div><br>
</div>
<div>Merci pour toutes vos réponses sur les différences NFC et NFD
du jeu de caractères UTF8. J'ai suivi la "sagesse de la foule",
et réécrit à la main depuis la machine Linux le nom des quelques
fichiers posant problème. Miracle, ils sont réapparus sous macOS
! Le dysfonctionnement n'avait donc rien à voir avec exfat.
C'était bien l'encodage NFD sur ces quelques fichiers qui
interdisait à macOS de les lister dans le répertoire.</div>
<div><br>
</div>
<div>Dommage que le gestionnaire de la mailing-list bloque les
pièces-jointes, je ne peux attacher une photo d'écran. Quand on
sait dans quelle direction chercher, il est plus facile de faire
attention aux détails. En voilà un, minuscule, qui apparaissait
à l'écran sous Linux, dans la graphie du nom de l'un des trois
fichiers. En alphabet slovaque, il existe la lettre "i"
accentuée, différente de la lettre "i" du code ASCII, surmonté
d'un simple point:</div>
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>lorsque le no; du fichier était encodé en UTF8 NFD
(visible sous Linux, invisible sous macOS), la lettre "i"
s'affichait surmontée d'un point **et** d'un accent,
superposés l'un sur l'autre; c'est ce détail dont j'ai pris
une photo d'écran; au passage, cette graphie me parait être
incorrecte en slovaque;</li>
<li>lorsque le non du fichier fut corrigé pour être encodé en
UTF8 NFC, la lettre "i" s'est alors affichée surmontée d'un
accent seul;</li>
</ul>
<div><br>
</div>
</div>
<div>Avec l'encodage NFD, le système affichait donc en réalité
deux caractères composés: "i" + accent; au contraire, en
encodage NFC, à la place du "i" le système affichait un autre
caractère, un "i" surmonté d'un accent, différent et indépendant
du "i" surmonté d'un point.</div>
<div><br>
</div>
<div>Reste à trouver pourquoi seuls 3 de ces fichiers, dans un
répertoire en comportant 11 autres (14 au total), ont été eux
nommés en encodage NFD ? J'ai dû faire une manip à la main dans
le temps, mais je serai incapable de dire depuis quel machine.</div>
<div><br>
</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div><font color="#000000">Le 18 avr. 2024 à 13:33, Marc
SCHAEFER via gull <a class="moz-txt-link-rfc2396E" href="mailto:gull@forum.linux-gull.ch"><gull@forum.linux-gull.ch></a> a écrit
:</font></div>
<font color="#000000"><br class="Apple-interchange-newline">
</font>
<div><font color="#000000"><span
style="font-family: Menlo-Regular;">Evidemment les 2
chaînes UTF-8 sont différentes en comparaison octet par</span><br
style="font-family: Menlo-Regular;">
<span style="font-family: Menlo-Regular;">octet, ce qui
explique le symptôme macOS X voit deux fichiers.</span></font></div>
</blockquote>
</div>
<div><br>
</div>
<div>Dans mon cas, macOS ne voyait pas du tout les quelques
fichiers dont le nom était encodé en NFD. Ces fichiers ne
possédaient pas de jumeau encodés en NFC dans le même
répertoire. Ils étaient donc simplement invisibles.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<blockquote type="cite"><font color="#000000">Le 18 avr. 2024 à
23:43, Samuel Chenal via gull
<a class="moz-txt-link-rfc2396E" href="mailto:gull@forum.linux-gull.ch"><gull@forum.linux-gull.ch></a> a écrit :</font></blockquote>
<blockquote type="cite"
style="font-family: Menlo-Regular, monospace;"><font
color="#000000"><br class="Apple-interchange-newline">
Petite expérience personnelle avec un samba sur Debian, en
external storage Nextcloud et qui supporte assez mal les
encodages Apple pour les caractères francophones. J'utilise
le petit programme convmv dans un cron, une fois par jour,
histoire de nettoyer les noms de ces fichiers Apple.</font></blockquote>
<br class="Apple-interchange-newline">
</div>
<div><br>
</div>
<div>J'avais monté un serveur de fichiers similaire (samba sur le
LAN + Nextcloud depuis l'extérieur), et activé sur samba les
extensions "fruits" prenant en gestion les spécificité de macOS.
Je n'ai pas rencontré l'incompatibilité dont tu parles. On peut
comparer nos fichiers de configuration de samba à l'occasion, si
tu veux.</div>
<div><br>
</div>
<div><br>
</div>
<div>
<blockquote type="cite" style="color: rgb(0, 0, 0);">
<div>Le 18 avr. 2024 à 07:55, felix via gull
<a class="moz-txt-link-rfc2396E" href="mailto:gull@forum.linux-gull.ch"><gull@forum.linux-gull.ch></a> a écrit :</div>
<br class="Apple-interchange-newline">
<div><span style="font-family: Menlo-Regular;">Première
question: pourquoi un FS Microsoft sur un disque qui</span><br
style="font-family: Menlo-Regular;">
<span style="font-family: Menlo-Regular;">n'est pas utilisé
sour MS?</span></div>
</blockquote>
<br class="Apple-interchange-newline">
</div>
<div><br>
</div>
<div>Parce que c'est très agréable de brancher sur divers OS un
volume externe dont le système de fichiers (exfat) ne gère pas
les droits d'accès, et de l'utiliser immédiatement, parce que
ça-juste-marche. Comme toi, j'ai fait le choix de HFS+ non
journalisé, pour un volume externe dont je savais à l'avance
qu'il serait utilisé sur macOS et Linux uniquement. Rien à dire
sur la robustesse, jamais de corruption irrécupérable
(contrairement à exfat), mais comme les utilisateurs sont
différents, la gestion des droits d'accès est chaotique. Il faut
à chaque fois se battre à coup de chmod, ce n'est pas pratique.
Pour des volumes amovibles, un système de fichiers sans gestion
des droits d'accès est franchement plus confortable à l'usage.
Si tu as une martingale pour corriger le phénomène sur HFS+, je
suis preneur avec plaisir.</div>
<div><br>
</div>
<div><br>
</div>
<div>
<blockquote type="cite"><span
style="font-family: Menlo-Regular;">Ce sont des fichier
AppleDouble, pas vraiement des méta-datas, une</span><br
style="font-family: Menlo-Regular;">
<span style="font-family: Menlo-Regular;">cuisine propre à
Apple. Ils seront créés sur n'importe quel FS qui</span><br
style="font-family: Menlo-Regular;">
<span style="font-family: Menlo-Regular;">n'est pas Mac.</span></blockquote>
</div>
<div><br>
</div>
<div>Ah?!? J'aurai pensé que sur d'autres systèmes de fichiers
gérant les attributs étendus, c'est grâce à eux que macOS
enregistrait ses méta-données. En même temps, je serai incapable
de faire une liste de systèmes de fichiers, autres que HFS+,
APFS, et FAT, compatibles avec macOS. Peut-on monter autre chose
sur macOS ? La question reste donc peut-être théorique.</div>
<br id="lineBreakAtBeginningOfMessage">
<div>
<meta charset="UTF-8">
<div>--<br>
Frédéric Dumas<br>
<a class="moz-txt-link-abbreviated" href="mailto:f.dumas@ellis.siteparc.fr">f.dumas@ellis.siteparc.fr</a><br>
<br>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
gull mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gull@forum.linux-gull.ch">gull@forum.linux-gull.ch</a>
<a class="moz-txt-link-freetext" href="https://forum.linux-gull.ch/mailman/listinfo/gull">https://forum.linux-gull.ch/mailman/listinfo/gull</a></pre>
</blockquote>
<pre class="moz-signature" cols="72">--
_______________________________
Samuel Chenal
<a class="moz-txt-link-abbreviated" href="mailto:samuel.chenal@ll-dd.ch">samuel.chenal@ll-dd.ch</a>
<a class="moz-txt-link-freetext" href="https://www.ll-dd.ch">https://www.ll-dd.ch</a>
_______________________________
Empreinte GPG :
BD25 7B5F 442B DF2D 4E28
8203 B2A2 7269 4E00 5136
Merci d'utiliser des formats de
fichiers ouverts (comme ODF) !</pre>
</body>
</html>