10.12 Sierra Erreur "Nom interdit" et ses conséquences funestes

Nicomunich

Nouveau membre
3 Juin 2009
9
1
Munich
Bonjour à tous,

j'ai un souci a priori anodin mais qui s'est révélé plus compliqué à résoudre que prévu. J'ai changé de portable il y a un an pour un MBP 15" 2015. Migration de mes données depuis mon ancien Macbook, aucun problème.

Au premier lancement d'Onyx sur la nouvelle machine (pas immédiatement après la configuration de la nouvelle machine), il m'a signalé des problèmes sur la structure du disque => double erreur "Nom illégal". Pas moyen de réparer avec Utilitaire de disque => passage en Single User. C'est là que les ennuis sérieux ont commencé.

fsck -fy a corrigé les erreurs, sauf qu'après, plus moyen de booter: la barre de chargement avance très lentement et s'immobilise en plein milieu....et il ne se passe plus rien. Du coup, j'ait tenté plusieurs choses:

- Boot sur Recovery et sauvegarde depuis un clone => boot possible, ça tourne mais mon erreur est toujours là

- Même chose et sauvegarde depuis Time Machine => même situation

- Clean install: structure OK. Migration des donnés depuis Time Machine (ou le clone) => l'erreur "Nom interdit" revient. Du coup une chose est claire, il y a un truc qui cloche dans mes données.

Le scan du clone m'a montré que l'erreur y est également présente. Je pense donc pouvoir exclure un problème hardware.
Après recherche un peu poussée, j'en viens à soupconner les catalogues Lightroom. Si je supprime l'ensemble des catalogues et aperçus, je n'ai plus qu'une erreur au lieu de deux => problème non résolu.

J'ai aussi tenté de passer mes données au peigne fin pour trouver un réel problème sur un nom de fichier. Rien de probant.

Je n'ai trouvé aucune infos sur le web à propos d'un problème similaire. Ca n'est pas vraiment handicapant, mais c'est pas super pratique de devoir faire une clean Install à chaque mise à jour.

Comment est-ce que je peux trouver l'origine du problème ?
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 261
Forêt de Fontainebleau
Salut Nicomunich

Personne n'a d'idée, ou bien je n'ai pas été clair dans mes explications ?
Je pense que tu as été aussi clair que tu pouvais l'être - le problème étant d'interpréter l'expression : «  nom illégal » pour rechercher quel intitulé d'élément correspondrait à ce critère.

Tout ce que je peux avancer > c'est que le Finder n'admet pas d'intitulés incluant un « : » (deux points) - lesquels se trouvent convertis en « / » ; et que le système de fichiers HFS+ n'admet pas d'intitulés dépassant les 255 caractères.

Le problème > c'est que je ne suis pas sûr que l'expression : « nom illégal » signalée par «Onyx» corresponde bien à ce que je viens d'évoquer.

Tes manipulations semblent avoir montré qu'aucune erreur n'affectant une clean install > mais l'erreur intervenant à la récupération de tes données > les 2 éléments incriminés relèvent de ton dossier home (ton dossier de compte). En liaison probable avec des applications (d'après ta détection d'un élément relevant d'une bibliothèque de «Lightroom».

Tu peux toujours aller à : Applications > Utilitaires > pour lancer le «Terminal». Dans la fenêtre qui s'est ouverte > fais un copier-coller de la commande :
Bloc de code:
sudo find . -regex '.*[\:\].*' -print
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et de nouveau ↩︎

  • cette commande cherche dans l'espace de ton dossier de compte > les éléments dont l'intitulé inclut le caractère « : » et en affiche la liste

=> tu peux poster cette liste en copier-coller ici > mais attention  ! avant de faire ton coller > presse le bouton (4è avant la fin à droite) dans la barre de menus au-dessus du champ de saisie d'un message > menu : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité).

=> je me sens un tantinet ridicule avec cette commande à la noix qui retourne les intitulés comportant des « : » > car s'ils sont valides dans la "langue du Système" et que le Finder ait pour règle de convertir l'affichage de ces occurences à « / » --> il est difficile de concevoir en quoi il pourrait alors y avoir une erreur.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 261
Forêt de Fontainebleau
Tant qu'à proposer des commandes farfelues > en voici une seconde :
Bloc de code:
sudo find . | egrep '/[^/]{255,}$'
  • qui cherche dans le dossier home de l'utilisateur connecté les fichiers dont le nom comporte 255 caractères ou davantage > et retourne les intitulés précédés des chemins

=> poster ici le retour - s'il y en a un - ce pourrait désigner un élément dont l'intitulé serait invalide parce que trop long.
 

Nicomunich

Nouveau membre
3 Juin 2009
9
1
Munich
Merci pour l'info, je vais tester ce soir.

J'avais déjà fait une recherche sur les caractères potentiellement problématiques (%, /, : ) avec des utilitaires sans rien trouver. A voir au Terminal.
Je n'avais pas pensé à la longueur des noms de fichiers, on sait jamais...
 

r e m y

Cas clinique
Club MacG
4 Novembre 2000
41 490
4 290
58
St Germain en Laye - FRANCE
Le format HFS+ n'acceptant pas les noms de fichier de plus de 255 caractères, j'ai un peu de mal à imaginer que tu puisses en trouver un seul ne respectant pas cette contrainte.
Comment les caractères excédentaires auraient-ils pu être enregistrés dans le catalogue de fichiers???

La commande proposée par Macomaniac va peut-être te trouver des fichiers dont le nom fait 255 caractères, mais davantage j'en doute.
 

bompi

El Moderador
Modérateur
Club MacG
12 Février 2004
41 923
3 160
Cette erreur n'a pas l'air bien fréquente.
Sur un vieux fil, d'une autre époque (problème sur un G5...), le problème s'est ramené à des blocks défectueux sur le disque. Le seul moyen de vérifier le disque complètement est alors de faire une passe d'écriture de zéros sur le disque afin d'identifier les secteurs douteux [sur un SSD, on n'aime pas faire ça mais bon...]
 

Nicomunich

Nouveau membre
3 Juin 2009
9
1
Munich
Alors, voici ce que ça donne:

- recherche des ":":
Plein de cache safari:
Bloc de code:
./Library/Caches/Metadata/Safari/History/https:%2F%2Fwww.macg.co%2Ftests%2F2017%2F09%2Ftest-du-trackball-logitech-mx-ergo-99729%2Fpage%2F0%2F1.webhistory
./Library/Caches/Metadata/Safari/History/https:%2F%2Fwww.macg.co%2Ftests%2F2017%2F09%2Ftest-du-trackball-logitech-mx-ergo-99729.webhistory
Des données iWork:
Bloc de code:
./Library/Containers/com.apple.iWork.Keynote/Data/Library/Caches/Brushes/TSDBrushEnd_Chalk2_Chalk2:filled diamond.png
./Library/Containers/com.apple.iWork.Keynote/Data/Library/Caches/Brushes/TSDBrushEnd_Chalk2_Chalk2:filled square.png
Une flopée de logs liés à mon iPhone:
Bloc de code:
./Library/Logs/CrashReporter/MobileDevice/iPhone de Nicolas/WiFi/WiFiManager/wifi-buf-05-12-2017__18:16:53.log
./Library/Logs/CrashReporter/MobileDevice/iPhone de Nicolas/WiFi/WiFiManager/wifi-buf-05-12-2017__19:11:29.log
A priori pour tous ces fichiers-là, le nom est bien corrigé en remplaçant les ":" par un "/" dans le Finder:
Bloc de code:
TSDBrushEnd_Chalk2_Chalk2/filled diamond.png
- recherche des plus de 255 caractères: je n'obtiens que des entrées du cache de safari, dans le style:
Bloc de code:
./Library/Caches/Metadata/Safari/History/https:%2F%2Ftwitter.com%2FrealDonaldTrump%2Fstatus%2F863007411132649473?ref_src=twsrc%255Etfw&ref_url=http%253A%252F%252Fwww.lemonde.fr%252Fameriques%252Farticle%252F2017%252F05%252F12%252Fdonald-trump-met-en-garde-james-comey_5126927_3222.html.webhistory
./Library/Caches/Metadata/Safari/History/https:%2F%2Fwww.amazon.de%2FExpoImaging-ROGUEGRID2-Rogue-3-in-1-Wabenfilter%2Fdp%2FB00SYIW0U8%2Fref=pd_rhf_yast_s_cp_3?_encoding=UTF8&pd_rd_i=B00SYIW0U8&pd_rd_r=5A5FB879QD1KTZV57J82&pd_rd_w=uWuT0&pd_rd_wg=MKnaQ&psc=1&refRID=5A5FB879QD1KTZV57J82.webhistory
Est-ce que ça apporte quelque chose?

Cette erreur n'a pas l'air bien fréquente.
Sur un vieux fil, d'une autre époque (problème sur un G5...), le problème s'est ramené à des blocks défectueux sur le disque. Le seul moyen de vérifier le disque complètement est alors de faire une passe d'écriture de zéros sur le disque afin d'identifier les secteurs douteux [sur un SSD, on n'aime pas faire ça mais bon...]
Si ca m'arrivait sur un seul disque je serais bien d'accord, mais j'ai le même problème sur mon clone. A la rigueur je peux bien lui faire une passe d'écriture, ce n'est pas un ssd...
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
73 362
22 261
Forêt de Fontainebleau
Salut Nicomunich

Comme je m'y attendais > mes commandes n'ont rien retourné de significatif. Sauf en mode négatif (ce qui n'est pas absolument rien) : on sait désormais que les « noms illégaux » ne sont ne sont pas des noms incluant des « : » (puisque le Finder restitue bien ce caractère par une « / ») > ni des noms dépassant les 255 caractères ou plus (parce que, de toute façon, en cas de dépassement le système de fichiers JHFS+ aurait banni ces intitulés).

Il faudrait donc trouver une autre interprétation de « nom illégal » > mais je n'ai pas de meilleure idée à ce sujet.

Tu pourrais déjà supprimer tes catalogues «Lightroom» (du volume de ton OS) > puis les ré-injecter à partir de ton clone l'un après l'autre en testant à chaque fois > afin de pouvoir pointer le coupable ce qui limiterait le champ des recherches.

Ensuite > à supposer un seul catalogue «Lightroom» incriminé > est-ce qu'il se compose d'un très grands nombre d'objets nantis d'intitulés ou pas (j'ignore tout de cette application) ? - tu me vois venir --> tenter de restreindre le champ des objets > jusqu'à pouvoir demander (voire poster) une liste pas exagérément longue > afin de pouvoir inspecter les titres pour deviner si l'un d'entre eux n'excèderait un certain protocole de dénomination partagé par tous les autres.

Je sais : ça fait un peu travail de bénédictin...
 

Nicomunich

Nouveau membre
3 Juin 2009
9
1
Munich
Bonsoir,

@macomaniac: ce que tu proposes est effectivement ce que j'entrevois comme seule solution possible pour trouver l'origine du problème. J'ai plusieurs catalogues Lightroom, du coup je peux faire ça petit à petit.
Pour info, les catalogues Lightroom sont en plusieurs parties:
- le catalogue en lui-même, qui contient le référencement des photos et l'historique des modifications
- un paquet contenant les aperçus dits standards
- un autre paquet avec les aperçus dits dynamiques
=> pour mon plus gros catalogue (55 000 photos), ça fait un total d'environ 90Go - les photos elles-mêmes sont stockées sur un NAS. Je peux imaginer que les aperçus posent un problème quelque part, la structure est assez bizarre.

Ca me prendra un moment, mais je devrais m'en sortir. Je ferai ça proprement après l'installation de High Sierra, c'est l'occasion !