J'ai reçu récemment un tas de fichiers HTML sur une clé USB (FAT32), qui ont été créés sur un système Windows, mais avec des fins de ligne LF. Je les ai vérifiés dans mon navigateur (Firefox) sous MacOS 10.14, et comme sur l'un d'eux j'ai trouvé quelques changements à faire, j'ai lancé mon éditeur de texte et modifié ce fichier. Après l'avoir sauvegardé, j'ai essayé de le recharger, mais Firefox refuse maintenant de l'afficher et dit qu'il a aucune permission pour ouvrir ce fichier.
J'ai vérifié le fichier à partir de la ligne de commande, et j'ai constaté que je pouvais afficher le fichier en utilisant
less /Volume/Stick/original/x.htmlbien et mes changements étaient également présents. J'ai essayé de redémarrer Firefox, et même de redémarrer le Mac lui-même, en vain. D'autres navigateurs (Vivaldi, Chrome) n'ont pas pu non plus ouvrir le fichier. En regardant ce répertoire /Volume/Stick/original en utilisant Finder J'ai vu que le Finder pouvait afficher un aperçu de tous les autres fichiers (y.html, z.html), mais pas de x.html que j'avais modifié.
Ensuite, j'ai fait un
ls -l /Volume/Stick/originalet j'ai constaté que tous les fichiers "fonctionnels" (y, z, ...) affichaient les permissions suivantes rwxrwxrwx (le bit x inutile est peut-être un artefact dû au fait que les fichiers ont été créés sous Windows), mais le fichier x.html présentait les permissions suivantes rwxrwxrwx@ . D'après moi, le @ indique que l'entrée du répertoire est en réalité un lien, mais ls n'a pas montré où il serait lié. Faire un stat de ce dossier n'a pas non plus permis d'en savoir plus.
Pour expérimenter un peu, j'ai fait un
mkdir /Volume/Stick/copy
cp -v /Volume/Stick/original/* /Volume/Stick/copy créant ainsi une copie de ces fichiers. A
ls -l /Volume/Stick/copy/x.htmla aussi montré le @ dans les permissions du fichier copié. Cependant la version copiée, copy/x.html peut être ouvert sans problème à partir de n'importe quel navigateur, même le original/x.html ne peut pas. Même après avoir recopié de manière redondante le fichier cassé avec la fonction
cp -v /Volume/Stick/copy/x.html /Volume/Stick/originalla version de original/x.html était inutilisable de la même manière qu'avant.
Bien sûr, je dispose maintenant d'une version entièrement fonctionnelle dans /Volume/Stick/copy Mais j'aimerais quand même comprendre ce qui s'est passé ici, et pourquoi l'édition du fichier a détruit le fichier, alors qu'une copie de ce fichier édité ne présente aucun problème.
Je pense que le problème est lié au fait que la FAT32 gère les fichiers selon le fameux schéma de nommage 8.3 de MSDOS, et qu'une entrée fantôme est utilisée pour stocker le "vrai" nom de fichier ; mais je ne vois pas comment cela pourrait expliquer le comportement que j'ai rencontré, car je n'ai jamais eu de problèmes jusqu'à présent en créant des fichiers sur une clé USB sur le Mac.
Des idées, comment expliquer ce mystère ?
UPDATE :
Suivant le commentaire donné par gidds qui a fait remarquer que le @ n'indique pas un lien symbolique ici, mais un attribut étendu, j'ai appliqué un ls -l@ aux deux fichiers (l'original non fonctionnel, et la copie fonctionnelle). Dans les deux cas, le résultat était
com.apple.lastuseddate#PS 16Probablement que date de la dernière utilisation a été défini lorsque j'ai édité le fichier. J'ai ensuite fait un xattr -p pour cet attribut, et les deux ont montré
69 FE DA 61 00 00 00 00 F0 9F C2 33 00 00 00 00Je ne peux pas dire si cette valeur est raisonnable, mais comme la même valeur est indiquée dans les deux fichiers, cela n'explique pas pourquoi un fichier "fonctionne" et l'autre pas.
TROUVER UNE CORRECTION (mais ne peut toujours pas le comprendre) :
Tout d'abord, j'ai constaté que le redémarrage du Mac a résolu le problème dans la mesure où le fichier ne peut plus être traité ensuite par tous les navigateurs, et où l'aperçu dans le Finder semble correct. Cependant, l'édition du fichier - ou, d'ailleurs, de tout autre fichier sur la clé USB - a provoqué la réapparition du problème.
Après quelques expérimentations, j'ai découvert que le problème était lié à une éditeur de texte particulier . J'ai utilisé le Rédacteur en chef pour éditer le fichier, et avec cela, les choses se cassent si le fichier est sur une clé USB.
Si, après le redémarrage, j'ai édité le fichier en utilisant Tincta à la place, tout va bien.
De plus, j'ai remarqué qu'une fois que j'avais obtenu un fichier cassé avec l'éditeur Cot, je pouvais également le réparer en copiant d'abord le fichier cassé sur la ligne de commande vers un autre fichier temporaire, puis en effaçant le fichier cassé, et enfin en le recopiant à partir du fichier temporaire.
Je ne sais pas ce que Cot Editor fait spécialement avec ces fichiers, mais à un moment de mes expériences, quand j'ai voulu quitter Cot Editor, j'ai eu un message pop-up disant : "Le document x.html se trouve sur un volume qui ne supporte pas le stockage permanent des versions". J'ai vu ce message pour la première fois et je ne sais pas ce qu'il signifie, mais au moins, il montre qu'il y a un problème avec la version permanente. est quelque chose de spécial à propos du volume USB qui dérange cet éditeur de texte.
