Salut Frédéric,
J'ai également les directives "fruit" dans mon smb.conf.
# Mac
vfs objects = catia fruit streams_xattr
fruit:metadata = netatalk
fruit:model = MacSamba
fruit:posix_rename = yes
fruit:veto_appledouble = no
fruit:resource = file
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
fruit:time machine = no
fruit:encoding = native
fruit:aapl = yes
Peut-être qu'une de ces directives doit être changée.
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.
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 :
Ready! I converted 13 files in 69 seconds.
Sur ~720Go de données.
a+
Samuel
Le 20.04.24 à 10:56, Frederic Dumas via gull a écrit :
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.
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:
* 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;
* 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;
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.
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.
Le 18 avr. 2024 à 13:33, Marc SCHAEFER via gull
<gull@forum.linux-gull.ch> a écrit :
Evidemment les 2 chaînes UTF-8 sont différentes en comparaison octet par
octet, ce qui explique le symptôme macOS X voit deux fichiers.
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.
Le 18 avr. 2024 à 23:43, Samuel Chenal via gull
<gull@forum.linux-gull.ch> a écrit :
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.
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.
Le 18 avr. 2024 à 07:55, felix via gull <gull@forum.linux-gull.ch> a
écrit :
Première question: pourquoi un FS Microsoft sur un disque qui
n'est pas utilisé sour MS?
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.
Ce sont des fichier AppleDouble, pas vraiement des méta-datas, une
cuisine propre à Apple. Ils seront créés sur n'importe quel FS qui
n'est pas Mac.
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.
--
Frédéric Dumas
f.du...@ellis.siteparc.fr
_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull
--
_______________________________
Samuel Chenal
samuel.che...@ll-dd.ch
https://www.ll-dd.ch
_______________________________
Empreinte GPG :
BD25 7B5F 442B DF2D 4E28
8203 B2A2 7269 4E00 5136
Merci d'utiliser des formats de
fichiers ouverts (comme ODF) !
_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull
