Hace poco recibí un montón de archivos HTML en una memoria USB (FAT32), que fueron creados en un sistema Windows, pero con terminaciones LF-line. Los revisé en mi navegador (Firefox) en MacOS 10.14, y como en uno de ellos encontré algunos cambios por hacer, encendí mi editor de texto y modifiqué ese archivo. Después de guardarlo, intenté volver a cargarlo, pero Firefox se negó ahora a mostrarlo y dijo que tiene sin permiso para abrir este archivo.
Revisé el archivo desde la línea de comandos, y encontré que podía mostrar el archivo usando
less /Volume/Stick/original/x.htmlbien y mis cambios también estaban presentes. Intenté reiniciar Firefox, e incluso reiniciar el propio Mac, sin éxito. Otros navegadores (Vivaldi, Chrome) tampoco pudieron abrir el archivo. Mirando ese directorio /Volume/Stick/original utilizando Finder En el caso de los archivos de la serie "Y", vi que Finder podía mostrar una vista previa de todos los demás archivos (y.html, z.html), pero no de x.html que había modificado.
A continuación hice un
ls -l /Volume/Stick/originaly encontré que todos los archivos "de trabajo" (y, z, ...) mostraban sus permisos como rwxrwxrwx (el innecesario x-bit tal vez un artefacto del hecho de que los archivos fueron creados en Windows), pero el archivo x.html mostró los permisos como rwxrwxrwx@ . AFIK, la @ indicaría que la entrada del directorio es en realidad un enlace, pero ls no mostró dónde se vincularía. Haciendo un stat de este archivo tampoco proporcionó más información.
Para experimentar un poco, hice un
mkdir /Volume/Stick/copy
cp -v /Volume/Stick/original/* /Volume/Stick/copy creando así una copia de esos archivos. A
ls -l /Volume/Stick/copy/x.htmltambién mostró la @ en los permisos en el archivo copiado. Sin embargo la versión copiada, copy/x.html puede abrirse desde cualquier navegador sin problemas, incluso el original/x.html no puede. Incluso después de copiar redundantemente el archivo roto con
cp -v /Volume/Stick/copy/x.html /Volume/Stick/originalla versión de original/x.html era inutilizable de la misma manera que antes.
Por supuesto, ahora tengo una versión que funciona perfectamente en /Volume/Stick/copy Pero todavía me gustaría entender qué ha pasado aquí, y por qué la edición del archivo arruinó el archivo, aunque una copia de ese archivo editado no tiene ningún problema.
Mi mejor conjetura es que el problema está relacionado de alguna manera con el hecho de que FAT32 básicamente mantiene los archivos de acuerdo con el infame esquema de nomenclatura 8.3 de MSDOS, y alguna entrada en la sombra se utiliza para almacenar el nombre de archivo "real"; pero no veo cómo esto podría explicar el comportamiento que experimenté, porque nunca hasta ahora he tenido problemas al crear archivos en una memoria USB en el Mac.
¿Alguna idea para explicar el misterio?
ACTUALIZACIÓN :
Tras el comentario de gidds que señaló el @ no indica aquí un enlace simbólico, sino un atributo extendido, he aplicado un ls -l@ a ambos archivos (el original que no funciona y la copia de trabajo). En ambos casos, la salida fue
com.apple.lastuseddate#PS 16Probablemente eso última fecha de uso se estableció cuando edité el archivo. Luego hice un xattr -p para este atributo, y ambos mostraron
69 FE DA 61 00 00 00 00 F0 9F C2 33 00 00 00 00Aunque no puedo decir si este valor es razonable, pero ya que el mismo valor se muestra en ambos archivos, no explica por qué un archivo "funciona" y otro no.
ENCONTRADO UN REMEDIO (pero sigue sin entenderlo):
En primer lugar, he comprobado que reiniciar el Mac ha solucionado el problema, ya que el archivo no puede ser procesado después por todos los navegadores, y además la vista previa en Finder se ve bien. Sin embargo, al editar el archivo -o, para el caso, cualquier otro archivo en la memoria USB- el problema volvió a ocurrir.
Después de algunos experimentos, descubrí que el problema estaba relacionado con un editor de texto particular . Utilicé el Editor de cotas para editar el archivo, y con esto, las cosas se rompen si el archivo está en una memoria USB.
Si, después de reiniciar, edité el archivo usando Tincta en cambio, todo está bien.
Además, me di cuenta de que, una vez que tenía un archivo roto con el Editor Cot, también podía arreglarlo copiando primero el archivo roto en la línea de comandos a algún otro archivo temporal, luego borrar el archivo roto y, finalmente, volver a copiarlo desde el archivo temporal.
No sé qué hace Cot Editor especialmente con esos archivos, pero en un momento de mis experimentos, cuando quise salir de Cot Editor, me salió un mensaje emergente que decía "El documento x.html está en un volumen que no admite el almacenamiento permanente de versiones". He visto este mensaje la primera vez y no sé, lo que significa, pero al menos muestra que hay es hay algo especial en el volumen del USB que molesta a este editor de texto.
