Buenas,
No me presenté, soy un internetero anónimo más, con ganas de aportar algo.
Hace poco que les trasladé de compañía a familiares a O2, y me está pareciendo bien, habrá gente que no.
Me encontré con que regalaban O2-Cloud, que me viene genial ya que justo otras cosas gratuitas ya me protestaban de que se estaban quedando sin espacio. Así que guay, me instalo el software de sincronización y a vivir.
Es una pena que esta nube no ofrezca una forma de uso estándar y abierto (una fachada, interfaz, API, protocolo,… ). Ofrecen la app propietaria. La forma de usarla es tirar un montón de ficheros en una carpeta y esperar a que la app haga lo suyo y las sincronize en la nube. Una vez ahí la nube de archivos se maneja desde diversos dispositivos.
Hasta ahí bien. El problema es cuando la sincronización se detiene. :-O Pánico, rabia, espumarajos y antorchas ardienetes. Porque en internet hay zero absoluto de información técnica sobre esta nube, lo que nos deja en el averno del sistema de soporte de la compañía, perded toda esperanza.
A mí es lo que me pasó. Rascando sobre el tema, hay un rastro de que el software derivado de un producto vintage llamado Funambol que consiste en eso, una empresa que fabrica nubes privadas de marca blanca a operadores (lo mismo que Tvup ofrece paquetes de TV). Funambol debio ser abierto en algún momento, usando protocolo syncML y pensado para móviles para sincronizar contactos, luego añadieron soporte para fotos, documentos y finalmente carpetas de archivos en general. Las fuentes aun se pueden encontrar en sourceforge, y sacarlas con lo que había antes de git: subversion (svn). Nombres de clases y similar apareciendo en el log de o2-cloud evidencian de donde viene. Gazapos del log que no están en las fuentes indican un software modificado (p. ej. "continbue").
Hacer algo con ese código fuente anticuado es muy costoso. Lo que es útil es ver qué ficheros genera la aplicación en ejecución. Centrándonos en Windows, las carpetas que yo veo:
- C:/Program Files (x86)/O2 Cloud → ahí es donde se instala la aplicación en sí, ejecutables etc. (en opción instalar para todo el mundo, si se instala para un usario concreto va en otro sitio)
- <home>/AppData/Local/O2Espana/O2 Cloud → cosas internas de la aplicación, rollos del estado del QtWebEngine. (es una app de esas que envuelven una web). <home> es p. ej. c:/Users/paco
Esas dos no aportan mucho. Adicionalmente está la carpeta que hemos configurado para sincronizar. En ella habrá lo que usuario haya metido para tener en la nube.
Lo interesante está en "<home>/.config/O2Espana/O2 Cloud". Ahí hay una carpeta de logs, donde está el mismo que se puede ver en la app nubecilla→piñón→ajustes→avanzado→ver registro…
El problema de los logs es que están "sanitizados", quizá por legislación, ya que los logs los puede mandar la app o circulan durante un soporte. No referencian archivos concretos, solo identicadores que no nos dicen nada como usuarios (por ejemplo el log que te dice que la sincronización se ha parado por un error InvalidParam en fichero 653234).
En <home>.config/O2Espana/O2 Cloud/cache/XXXXX (XXX=número mágico) está lo bueno. Ahí ya vemos un .history con algunos nombres de fichero, unos cuantos. thumb/ es el caché de iconcitos de vista previa para la app de la nubecilla. Lo que interesa son los ficheros DB.
Sqlite es una base de datos soprtada por fichero (un fichero, una base de datos). Y si uno tiene la utilidad necesaria, se puede ver lo que hay dentro. Buscando "sqlite3 windows" se encuentra lo necesario. Que si con GUI o para la terminal, que si instalador o portable, y si instalar desde gestor de paquetes (chocolatey/scoop) o a mano. No doy más detalles. En mi caso yo tengo sqlite3.exe en la PATH y lo puedo invocar en la terminal. Abro el fichero más importante:
> sqlite3.exe media_items.db
SQLite version 3.28.0 2019-04-16 19:49:53Las bases de datos tienen tablas, las tablas tienen registros, los registros tienen columnas y las columnas valores.
Para ver el aspecto de las tablas de media_items.db:
> .schema
CREATE TABLE items_store_version (store_version INTEGER);
CREATE TABLE media_items (id INTEGER PRIMARY KEY AUTOINCREMENT,luid TEXT,guid TEXT,name TEXT,size INTEGER,creation_date INTEGER,modification_date INTEGER,content_type TEXT,status INTEGER,server_last_update INTEGER,url TEXT,parent_guid TEXT,remote_item_url TEXT,num_upload_failures INTEGER,local_item_path TEXT,remote_item_etag TEXT,local_item_etag TEXT,validation_status INTEGER,parent_folder_id INTEGER,server_modification_date INTEGER,checksum TEXT);
CREATE TABLE sqlite_sequence(name,seq);hay tres tablas, la que importa es "media_items" (mismo nombre que el del fichero de la base de datos, casualidades). Ahi está lo que importa. Los registros de la tabla son los ficheros que la nube sabe que tiene que manejar, y que corresponden a archivos en cualquiera de los subdirectorios de la carpeta de sincronización configurada en la app. La columna "name" es el nombre real del fichero. Las columnas id, luid y guid son distintos números identificativos del fichero, como sus DNIs o matrículas. Si no recuerdo mal, los números que aparecen en los mensajes de error de los ficheros de error de la apliación de sincronización de la nube, son los GUIDs.
Para consultar la base de datos hay un complejo lenguaje de consulta. A día de hoy uno puede ir a DeepSeek (o similar) y preguntar
Asumiendo que el esquema de una base de datos sqlite3 es el siguiente:
CREATE TABLE items_store_version (store_version INTEGER);
...<pegar lo de arriba>
escribe una consulta para ver las columnas name y guid de los registros de la tabla media_items.Deepseek contesta
SELECT name, guid FROM media_items;Que lo podemos pegar directamente en el prompt de qlite3
sqlite> SELECT name, guid FROM media_items LIMIT 10;y contesta:
elephant.txt|652691384
stdafx.cpp|652691387
c2.cmd|652691389
asdf.md|652691390
log.bat|652691391
...Con lo que voi-lá, ya hemos podido averiguar, a partir de un incomprensible número en el fichero de log, a qué fichero concretamente se está refirendo el mensaje del log del software de O2.
En mi caso era un nombre lleno de caracteres raros bastante largo. Lo borré y la sincronización terminó del tirón.
La tabla media_items.db es el conjunto total de ficheros, olvidando las carpetas. Las carpetas están en la base de datos del fichero folder_items.db. Los registros son carpetas, la columna name es el nombre, y la columna parent_id el ID de la carpeta padre. Es un viejo truco de como representar árboles en tablas. Por ejemplo la carpeta "luke skywalker" tiene como parent_id el "id" de la carpeta "darth vader".
En principio eso es todo el pescado, ofrecido como servicio público. Si las cosas de los americanos están tan bien documentadas es por gente que se toma la molestia. Esta información no es para principiantes, manejar estas bases de datos puede corromper el conjunto de los datos sincronizados, el autor no se responsabiliza del mal uso. No dar la vara al soporte oficial citando estos detalles si se quiere que sigan siendo igual de accesibles en un futuro.
