Estoy publicando esta respuesta solo para decir cómo se resolvió el problema, resumiendo así los comentarios hechos a la pregunta original, que podrían ser útiles para otros.
Solucioné el problema en Linux, donde se habían creado esas carpetas, simplemente acortando el título de dos o tres de los archivos de video, que tenían nombres largos pero sin caracteres obviamente extraños como comas, corchetes, etc. También cambié la carpeta. nombres, aunque no tenían nada especial. Cambiarlos de nuevo no reprodujo el problema.
Entonces, los nombres de las carpetas tenían algún carácter incorrecto que no era visible como tal en Linux, o los caracteres incorrectos en algunos de los tres archivos que se renombraron hicieron que toda la carpeta fuera invisible en Mac y todo. su contenido no se puede reproducir en Windows.
Esto es lo más raro que, antes de renombrar las carpetas y los tres archivos, ninguno de los archivos se podían reproducir en Windows.
Podría haber sido, como dijo @Giacomo1968 en un comentario:
'... un carácter "fantasma" en el nombre de archivo original... Algo así como un retorno de carro o un espacio sin interrupciones que se manejaba de una manera en Linux, pero se ahogaba en otros sistemas.'
El caso es que antes de solucionar el problema he probado a reproducir en Windows otros archivos distintos a los que al final se renombraron. El personaje fantasma también podría haber estado en los nombres de las carpetas.
Me sucedió nuevamente en una nueva unidad formateada como exFAT con otros archivos en una carpeta sobre la cual el administrador de archivos Nemo informó un error en Linux durante la copia (algo así como "no se puede crear el archivo"), pero de hecho todo se veía bien en linux Esa carpeta se vio pero permaneció completamente inaccesible en Windows (no recuerdo exactamente el mensaje de error, algo sobre el archivo o la carpeta que no existe), y se vio en una Mac, excepto un solo archivo, que permaneció invisible. Después de renombrar en Linux la carpeta y el archivo con el mismo nombre todo salió normalmente!
Ahora sospecho que la causa del problema inicial informado en la pregunta, y la creación de un personaje 'fantasma' incorrecto, fue un error durante un proceso de copia o el pegado en título de texto copiado de páginas de internet (donde lo que parece un espacio, por ejemplo, es en realidad otra cosa). Esto me lo sugirió el hecho de que, al copiar con Double Commander en Linux, informó errores detallados en algunos nombres que incluyen espacios que podrían haber sido caracteres de tabulación o algo similar.
Al final, la mejor solución para copiar fue usar Double Commander en Linux, que indicaba muy claramente el nombre del archivo que tenía problemas.
Copiar/pegar texto de Internet al nombrar archivos o carpetas debe hacerse con precaución.
La forma en que funcionan los nombres de archivos/carpetas en Windows se analiza en el sitio web de Microsoft. Sin embargo, eso proporciona solo un atisbo de la verdad general.
NB:no discuta el aspecto de los problemas de página de códigos que pueden surgir de la forma en que un sistema "extranjero" accede a un volumen NTFS. Creo que esto está suficientemente cubierto en los comentarios y la otra respuesta. Me limitaré en gran medida a los dos aspectos siguientes:
- limitaciones de longitud de nombre de ruta
- combinaciones de caracteres a las que es difícil/imposible acceder desde el subsistema Win32
En cuanto al sistema de archivos, me limitaré a NTFS, al igual que la pregunta. Considere el siguiente comentario del sitio web vinculado anteriormente:
No termine un nombre de archivo o directorio con un espacio o un punto. Aunque el sistema de archivos subyacente puede admitir dichos nombres, el shell de Windows y la interfaz de usuario no .
Ahora, primero debemos aclarar parte de la terminología. Nos ocupamos de varias... capas, es probablemente un término adecuado:
- sistema de archivos, p. NTFS
- Administrador de objetos NT y otras funciones del kernel, pero cuando se trata de nombres principalmente el administrador de objetos
(si quiere verlo, use una herramienta como WinObj) - Subsistema Win32 (a esto se refiere la declaración anterior como "interfaz de usuario y shell de Windows")
- Otro "metaaspecto" sería la versión del sistema operativo, ya que la longitud de la ruta admitida puede variar
Un buen método para jugar con esto es un recurso compartido de Samba que finge ser NTFS en el lado del cliente. Pero un volumen NTFS de Windows también funcionará. Estaremos en Windows y "jugaremos" desde la línea de comando (presione Ganar +R y escribe cmd , luego presiona Entrar ).
Volumen NTFS local
Supongamos que quisiéramos crear un nombre de archivo no válido (¡¿observa el punto final?!):
echo NONSENSE > text.txt.
Al intentar esto, el resultado será test.txt , no test.txt. . El subsistema Win32 (csrss.exe) nos impidió hacer estupideces. Hmm, interesante, ¿eh?
Considere esta otra declaración:
No utilice los siguientes nombres reservados para el nombre de un archivo:
CON , PRN , AUX , NUL , COM1 , COM2 , COM3 , COM4 , COM5 , COM6 , COM7 , COM8 , COM9 , LPT1 , LPT2 , LPT3 , LPT4 , LPT5 , LPT6 , LPT7 , LPT8 y LPT9 . También evite estos nombres seguidos inmediatamente por una extensión; por ejemplo, NUL.txt no se recomienda.
Mmmm, NUL suena divertido. Lo sabemos por ser un sustituto de /dev/null en sistemas unixoid, heredado de la época de DOS.
echo NONSENSE > NUL
Correcto. Es un sustituto de /dev/null , por lo que la salida se tragará. Pero no usar suena muy tentador. Entonces, usemos la información resumida de un artículo de blog de Project Zero, sección "Dispositivo local".
Breve interludio:%CD%
Si no está muy familiarizado con la línea de comandos clásica de Windows (cmd.exe ), la variable especial %CD% nos dará la ruta absoluta al directorio de trabajo actual. Téngalo en cuenta para la siguiente sección. Entonces, si actualmente estuviera dentro de C:\test , el comando echo %CD% produciría la salida C:\test . Es un atajo conveniente para nuestros experimentos.
Como podemos deducir del artículo de Project Zero, hay varias formas de esquivar las conversiones de nombre de ruta en el nivel del subsistema Win32. Uno de esos métodos es el prefijo \\?\ que internamente directamente se traduce a \??\ , que en las versiones más recientes de Windows es idéntico a \GLOBAL??\ . Esto se denomina directorio de objetos (no lo confunda con entidades del sistema de archivos , ¡a pesar de la terminología similar!). Una vez más, WinObj y herramientas similares le permiten investigar el espacio de nombres del administrador de objetos.
Interludio:espacios de nombres y "cosas" del servidor de terminal
Cualquiera que haya echado un vistazo a la historia de Windows NT, y Windows 10 se remonta a NT, recordará una época en la que tenía que licenciar por separado los servicios de terminal. Es decir. la capacidad de conectarse a una sola máquina de forma remota con diferentes usuarios.
Creo que fue Windows XP el que finalmente trajo esto para las masas al permitir permanecer conectado con varias cuentas de usuario simultáneamente ("cambio de usuario"), y probablemente Windows 2000 o 2003 Server lo incluyeron en la edición estándar, aunque las CAL se necesitaban más allá de los "asientos" mínimos incluidos por defecto.
Aquí es donde la distinción entre \?? y \GLOBAL?? se origina \GLOBAL?? es la vista de los nombres de dispositivos "DOS" compartida por todos sesiones de inicio de sesión.
\?? se ve hoy en día en el enlace simbólico (nuevamente, ¡no es una entidad del sistema de archivos! ) llamado \DosDevices , lo que da una pista sobre su origen. Aquí es donde los nombres de los dispositivos "DOS", como C: o asignaciones de unidades de red residen. En un sistema moderno C: a su vez sería un enlace simbólico a \Device\HarddiskVolume1 (o similar). Eso suele ser un real objeto de dispositivo que fue creado por algún controlador en la pila de controladores de almacenamiento, en este caso debería ser el controlador del sistema de archivos NTFS.
Entonces, cuando haces doble clic en C:\Windows\explorer.exe lo que sucede internamente es que la ruta se convierte:
- En el nivel del subsistema Win32, el cambio habitual será anteponer
\??\. - El administrador de objetos luego expandirá el
\??\C:.- Primer
\??\termina en el espacio de nombres del dispositivo "DOS" para su sesión de inicio de sesión (vea el comentario a continuación) - Eventualmente, el administrador de objetos descubre algo como
\??\C:siendo equivalente a\GLOBAL??\C:que, como vimos anteriormente, es equivalente a\Device\HarddiskVolume1.
- Primer
El administrador de objetos luego pasará el resto de la ruta \Windows\explorer.exe al controlador responsable del objeto de dispositivo \Device\HarddiskVolume1 , asegurándose de que el controlador sepa a qué objeto de dispositivo se hizo referencia. Y ese controlador sabrá cómo manejar ese resto particular de la ruta dentro de su propio espacio de nombres.
Observación: Cuando te refieres a \?? internamente, termina con una vista de los dispositivos "DOS" de su sesión de inicio de sesión local. Esto se puede explicar mejor con unidades de red asignadas. Digamos que tiene una letra de unidad X: asignado para un recurso compartido remoto. Y supongamos que utiliza el "cambio de usuario" o que se está ejecutando en un servidor de terminal robusto donde otros doscientos usuarios están conectados simultáneamente. Tenemos dos problemas a la mano en tal escenario. Si bien la unidad del sistema (por ejemplo, el disco físico) puede ser compartida por todos, es posible que alguien de ventas haya mapeado "the cuota de ventas" como X: y alguien de desarrollo puede haber mapeado "the cuota de desarrollo". Lo mismo se aplica a una "letra de unidad" asignada a través de subst . Esto debería explicar por qué no puede haber un único espacio de nombres global para los nombres de dispositivos "DOS", que se ajuste a todos.
Así que nuestro objetivo era crear un archivo (o directorio) llamado NUL y el subsistema Win32 no nos dejaba. Simplemente absorbió la salida y el archivo nunca se creó en nuestro directorio de trabajo. Sin embargo, aprovechando la información del artículo vinculado anterior y el interludio anterior, podemos solucionar esto eludiendo esas molestas conversiones de ruta a nivel de subsistema emitiendo un:
echo NONSENSE > \\?\%CD%\NUL
Como recordatorio, %CD% se expande a la ruta absoluta del directorio de trabajo actual y, asumiendo que es C:\test , el comando anterior es equivalente a echo NONSENSE > \\?\C:\test\NUL .
Y he aquí, un rápido dir prueba que el archivo fue creado. Y si lo intentamos con otros nombres "reservados", también funciona bien.
Tenga en cuenta que también puede utilizar el real forma de ruta nativa de NT (\?? en lugar de \\? ) para el mismo efecto:
echo NONSENSE > \??\%CD%\NUL
Listo.
Entonces, ¿qué tal si revisamos el intento del punto final, pero dando la ruta completa sin que interfiera el subsistema Win32?:
echo ILLEGAL TRAILING DOT > \??\%CD%\test.txt.
Listo, funciona, como un rápido dir /b prueba:
C:\test>dir /b
CON
NUL
test.txt
test.txt.
Interludio:rutas UNC (Convención de nomenclatura universal)
Este tema se trata con más detalle en ese artículo de Project Zero, pero baste decir que hay una forma especial de ruta que se parece bastante a la que acabamos de usar arriba:\\.\C:\Windows\explorer.exe sería un ejemplo.
¿Recuerda que cada vez que está atascado en la pantalla de inicio de sesión, sin recordar el nombre de la máquina local de la máquina, y por defecto es el dominio del que es miembro? Una manera fácil de referirse a la máquina actual sin siquiera usar su nombre real es .\username , permitiendo referenciar al usuario username en la máquina actual .
El . en \\.\C:\Windows\explorer.exe debe entenderse de manera similar. En efecto, lo que estás diciendo es \\. en la máquina actual \C: en la unidad C: ruta de acceso \Windows\explorer.exe ... y las diferentes instalaciones del sistema operativo se unen entre sí para que esto suceda.
Cuidado :Las rutas UNC siguen un conjunto diferente de reglas, por lo que solo las menciono. Lea el artículo vinculado y el vínculo a la documentación de Microsoft si está interesado en obtener más detalles.
Ahora que finalmente hemos creado un archivo "imposible" test.txt. , vamos a echarle un vistazo, ¿de acuerdo?
C:\test>type test.txt
NONSENSE
¿Que demonios? Recuerdo claramente haber repetido ILLEGAL TRAILING DOT en ese archivo.
Por supuesto. Al igual que cuando inicialmente intentamos crear test.txt. el subsistema Win32 intervino nuevamente y "útilmente" convirtió nuestro nombre a test.txt . Así que en realidad estamos viendo \??\%CD%\test.txt en lugar de \??\%CD%\test.txt. .
Así que esto debería hacer:
C:\test>type \??\%CD%\test.txt.
ILLEGAL TRAILING DOT
Mucho mejor. El problema es que no todos los programas manejarán nuestra elusión furtiva de las conversiones de nombre de ruta de Win32 con tanta gracia como cmd.exe . Supongamos que queremos abrir el Bloc de notas:
C:\test>notepad \??\%CD%\test.txt.
Diablos, podemos ver el siguiente cuadro de mensaje:
Entonces, si bien hay formas de eludir algunas de las restricciones impuestas por el subsistema Win32, la utilidad de estos métodos es limitada y cuestionable.
Nota :Lectores que también desarrollan el software en/para Windows puede recordar que usar el prefijo \\?\ permitido eludir el MAX_PATH límite (solía ser 260, básicamente 255 más \\?\ y un \0 terminal ). Ahora sabe por qué esto nos permite hacer uso de aproximadamente 32767 caracteres. Dado que UCS-2 fue reemplazado por UTF-16 (creo que en XP), la manipulación de rutas en el nivel del administrador de objetos es solo un problema. Otra es que en UTF-16 un punto de código puede ocupar más de 16 bits (también conocido como wchar_t o WCHAR ), una vez que deje atrás el BMP.
De todos modos, la línea de comando (cmd.exe ) le brinda todas las herramientas para acceder y deshacerse de los archivos que pudo crear desde Windows en primer lugar.
Compartir Linux/Samba, haciéndose pasar por NTFS
Ahora partamos de la unidad local y consideremos una unidad de red asignada Z: , proporcionada por Samba 4.x, que imita una unidad NTFS en lo que respecta a Windows.
Este experimento ofrece algunas ideas más, porque podemos crear archivos de acuerdo con las reglas del lado de Linux y no tenemos que preocuparnos por no poder acceder a ellos desde el lado de Windows.
- La unidad asignada es
Z:y estaremos enZ:\testen el lado de Windows - En el lado de Linux, el volumen se formateó como btrfs
El artículo de Wikipedia nos dice todos los caracteres que no sean/y\0(también conocido como carácter ASCII NUL) ¡están permitidos! Así que esto debería ser divertido.
Aquí hay algunos nombres de archivos extravagantes que deberían (o al menos podrían) ser de difícil acceso en el lado de Windows, utilizando Bash en Ubuntu 20.04 en el lado de Linux para crearlos:
:.txt(creado conecho "$RANDOM" > \:.txt)???.txt(creado conecho "$RANDOM" > \?\?\?.txt).txt(creado conecho "$RANDOM" > .txt)*.txt(creado conecho "$RANDOM" > \*.txt)\.txt(creado conecho "$RANDOM" > \\.txt)".txt(creado conecho "$RANDOM" > \".txt)>.txt(creado conecho "$RANDOM" > \>.txt)<.txt(creado conecho "$RANDOM" > \<.txt)|.txt(creado conecho "$RANDOM" > \|.txt)
Esto debería cubrir prácticamente todas las bases, en realidad, pensándolo bien, es posible que el emoji ni siquiera sea un problema en absoluto. Las barras diagonales también están prohibidas en NTFS, pero eso también es válido para btrfs/POSIX/SUS.
Prueba desde el lado de Linux:
$ find -type f -printf '%P\n'
:.txt
???.txt
.txt
*.txt
\.txt
".txt
>.txt
<.txt
|.txt
Ahora veamos si y a qué podemos acceder desde el lado de Windows...
Z:\test>dir /b
_2X68P~X.TXT
_2X68Q~5.TXT
_2X68Q~9.TXT
_2X68Q~B.TXT
_2X68Q~D.TXT
_2X68R~7.TXT
_2X68S~3.TXT
_67V3K~2.TXT
.txt
Captura de pantalla como prueba:
¡Ohhhhh! Correcto, la herencia de DOS de Windows ataca de nuevo. NTFS, a menos que se deshabilite activamente, tiene la capacidad de crear los llamados nombres de archivo cortos 8.3, conforme a los requisitos de nombre de archivo de DOS.
Y así es como podemos acceder a los nombres de archivo no válidos independientemente.
Conclusión
Ahora recuerde, la pregunta era sobre una unidad NTFS externa, es decir, local. Esto significa que las reglas que acabamos de observar para las acciones de Samba pueden no aplicarse aquí.
Según el controlador utilizado para almacenar estos archivos (que puede variar según la versión de Linux/macOS, por ejemplo, ntfs-3g o el controlador de terceros utilizado, por ejemplo, el controlador de Paragon), veo las siguientes posibles causas después de ver los experimentos anteriores:
- el nombre del archivo contenía un
:,"o?... esto me parece lo más probable, dado que yo mismo había copiado y pegado accidentalmente títulos de libros electrónicos que contenían estos caracteres. Casi podemos descartar/y los otros caracteres "prohibidos" son al menos menos probables. - el lado de Windows y macOS ve el nombre no válido, intente ver el nombre de DOS 8.3, pero no se generó ninguno. Esto depende un poco de la versión exacta de Windows y su configuración, y dado que no tengo dispositivos macOS, tampoco puedo probar ese escenario. Además, no estoy seguro si en un sistema Windows donde los nombres 8.3 están habilitados Windows iría retroactivamente y generaría un nombre 8.3 si, por ejemplo, el lado de Linux se saltara esa parte. Porque si no recuerdo mal, el controlador NTFS decide si se completa el registro respectivo ("atributo").
- se excedió la longitud del nombre de la ruta. Creo que exceder la longitud de los segmentos de la ruta es imposible, porque NTFS no le permite almacenar más de 255 valores de 16 bits para un segmento de la ruta, pero también se puede haber excedido la longitud total de la ruta (vea este enlace).
Para el primer escenario, recomendaría usar fslint en el lado de Linux para desinfectar los nombres de los archivos (y carpetas). Existen otras herramientas similares y YMMV, elige.
Espero que esto ayude. Me llevó bastante tiempo volcar mis pensamientos por escrito.
Lecturas adicionales
- Nombrar archivos, rutas y espacios de nombres
- La guía definitiva sobre la conversión de ruta de Win32 a NT