ZimaOS 1.6.2 produjo al menos dos síntomas muy distintos en Files que no deben diagnosticarse como un solo error. Uno era una regresión reproducible al mover archivos, en la que el contenido se trasladaba, pero quedaba una carpeta de origen vacía. El otro implicaba errores de montaje y autorización de unidades en la nube que, en un caso verificado, desaparecieron después de actualizar completamente el navegador.
La regresión al mover carpetas tiene un límite importante en la versión actual: ZimaOS 1.7.1 corrigió explícitamente el problema de las carpetas vacías después de cortar. Si utilizas una versión estable actual y sigues viendo el mismo síntoma, confirma primero la versión exacta antes de aplicar soluciones antiguas para la versión 1.6.2.
Problema 1: Quedan carpetas de origen vacías después de mover archivos
El patrón informado era inusualmente específico: los archivos y subcarpetas se movían correctamente entre dos unidades SATA internas con formato ext4, pero la carpeta principal original permanecía vacía. Las operaciones de copia no mostraban el problema, y el comportamiento comenzó después de la actualización a la versión 1.6.2.
Cómo confirmar que tienes el mismo error
- Crea una carpeta de prueba pequeña que contenga una subcarpeta y algunos archivos.
- Muévela entre dos ubicaciones de almacenamiento local mediante la aplicación Files de ZimaOS.
- Confirma que todo el contenido llegue al destino.
- Comprueba si solo queda la carpeta principal vacía en el origen.
Si faltan archivos, cambian los permisos o el destino es un recurso compartido de red en lugar de almacenamiento ext4 local, se trata de una situación diferente y no debes asumir que la causa es esta regresión histórica.
La regresión al mover carpetas se corrigió en ZimaOS 1.7.1
Las notas de la versión de ZimaOS 1.7.1 indican explícitamente una corrección para las carpetas vacías que permanecían después de cortar carpetas en determinadas situaciones.
Por lo tanto, la mejor solución para un sistema que aún utiliza la versión 1.6.2 es actualizarlo a una versión estable actual después de hacer una copia de seguridad, no crear scripts que eliminen automáticamente las carpetas sobrantes.
Problema 2: La unidad en la nube muestra errores de almacenamiento no montado o de instancia
Los errores de las unidades en la nube pueden producirse en varias capas: la autorización del proveedor de nube, el token guardado por ZimaOS, el montaje del backend o el estado de la interfaz del navegador. Las capturas anteriores parecen mostrar un problema grave, pero un usuario del hilo del anuncio logró recuperarse al actualizar completamente la página, tal como sugirió IceWhale.
Paso 1: Actualiza completamente la página de ZimaOS
Una recarga normal puede reutilizar JavaScript obsoleto y datos de sesión almacenados en caché. Utiliza el método de actualización completa del navegador, vuelve a abrir Files y comprueba si la cuenta en la nube sigue apareciendo.
Paso 2: Comprueba si el proveedor es compatible actualmente
La guía actual de unidades en la nube de ZimaOS documenta la integración directa de Files con Google Drive, Dropbox y OneDrive, y la interfaz actual muestra los proveedores compatibles.
Paso 3: Vuelve a autorizar la cuenta solo si la sesión realmente está dañada
Si la unidad sigue sin estar disponible después de actualizar completamente la página, elimina y vuelve a conectar la cuenta únicamente después de confirmar que comprendes qué tareas locales dependen de ese montaje. Volver a autorizar la cuenta no debe ser la primera respuesta ante un problema que solo afecte a la visualización.
Cómo distinguir un problema de caché de la interfaz de un problema real de montaje
Un problema de la interfaz suele cambiar después de actualizar completamente la página, utilizar otro navegador o abrir una sesión privada nueva. Un problema de montaje del backend persiste en distintos navegadores y también puede afectar a las tareas de copia de seguridad o a las rutas de aplicaciones que utilizan el montaje en la nube.
Utiliza esta distinción antes de eliminar las credenciales. Si Files parece estar dañado en un navegador, pero funciona en otro, concéntrate en la sesión del frontend. Si todos los clientes y servicios ven el mismo almacenamiento ausente, investiga la capa de montaje o autorización.
No mezcles los errores al mover archivos locales con los errores de autenticación en la nube
El anuncio de la versión 1.6.2 recopiló muchos informes de actualización no relacionados. Es fácil convertir ese hilo en un artículo impreciso sobre “errores de almacenamiento”, pero eso dificulta la solución de problemas. El comportamiento de corte en ext4 local y los errores de OAuth o de montaje en la nube tienen evidencias, puntos de fallo y soluciones diferentes.
La descripción general de la integración en la nube ofrece un contexto más amplio sobre los flujos de trabajo en la nube y locales.
Qué hacer si el problema sigue existiendo en la versión actual de ZimaOS
Para el problema de las carpetas, registra la versión actual de ZimaOS, el sistema de archivos de origen y destino, si ambos son locales y si la operación fue cortar/mover o copiar. Para el problema de la nube, registra el proveedor, el navegador, el error exacto, si una actualización completa de la página lo modifica y si la unidad funciona desde otro cliente.
Esto permite que un nuevo informe de error sea útil, en lugar de asumir que ha regresado un defecto antiguo de la versión 1.6.2.
Preguntas frecuentes
¿ZimaOS 1.7.1 corrige la carpeta vacía que queda después de mover archivos?
Sí. Las notas de la versión 1.7.1 mencionan explícitamente la corrección de las carpetas vacías que podían quedar después de cortar carpetas en determinadas situaciones.
¿Debo eliminar manualmente las carpetas vacías en la versión 1.6.2?
Puedes eliminar los restos que hayas confirmado que están vacíos, pero actualizar es la mejor solución a largo plazo. No automatices la eliminación hasta verificar que ningún archivo haya fallado al moverse.
¿Por qué una actualización completa puede corregir un error de una unidad en la nube?
El navegador puede conservar un estado del frontend o datos de sesión obsoletos después de una actualización. Si el montaje del backend funciona correctamente, actualizar los recursos del frontend y la sesión puede restaurar la interfaz sin modificar la cuenta.
¿Debo desconectar y volver a conectar OneDrive o Google Drive inmediatamente?
No. Primero intenta actualizar completamente la página y utilizar otra sesión limpia del navegador. Vuelve a autorizar la cuenta solo cuando el montaje o el token sean realmente inválidos.
