Por qué una misma foto de continuidad tiene dos registros: los datos de la imagen y la ruta del archivo
Una foto de continuidad puede tener en SlateX dos registros de naturaleza distinta al mismo tiempo: los datos de la imagen guardados en la base de datos y la ruta relativa que apunta a un archivo en el disco dentro del espacio aislado (sandbox) de la app. Para mostrar, la interfaz lee los datos de la imagen; para borrar el archivo, depende de la ruta relativa que quedó guardada. Los dos sirven a acciones distintas, así que “la imagen todavía se ve” y “ese archivo del disco se puede encontrar con precisión y borrar” no son la misma cosa.
Los datos de la imagen responden “qué se muestra” y la ruta del archivo responde “cuál archivo se borra”; los dos registros no se sustituyen entre sí.
Para mostrar se leen los datos de la imagen y para borrar manda la ruta relativa
Las tarjetas, el detalle, la zona de referencias asociadas y la pantalla de comparación leen la foto desde los datos de la imagen que están en la base de datos, solo que cada interfaz usa un tamaño de miniatura distinto. Es decir, mientras los datos de la imagen sigan ahí, la interfaz tiene su propia fuente para mostrar y no necesita volver a abrir la foto yendo primero por la ruta del disco.
La lógica de borrado hace precisamente lo contrario. Al eliminar un medio o un archivo de la biblioteca de continuidad, el código localiza el archivo en el disco con la ruta relativa que fue persistida antes, y prohíbe expresamente volverse a inventar el nombre del archivo a partir de los campos del modelo actual. Sin una ruta exacta guardada, la lógica de borrado no recorre nombres a ver si encuentra “un archivo que se parezca”.
De ahí que una misma foto haya que entenderla a la vez como “objeto de la base de datos” y como “archivo del espacio aislado”. Que el objeto de la base de datos se pueda ver no equivale a que la ubicación autorizada del archivo en el disco esté registrada por completo; y que exista la ruta en el disco tampoco quiere decir que la muestra se apoye en ella a la inversa.
Las dos familias de fotos arman sus directorios de otra manera
El material de continuidad colgado de un registro de toma forma su ruta con la jerarquía de proyecto, escena, plano y toma; la portada o el material de referencia colgado de una entrada de la biblioteca de continuidad forma el nombre del archivo según la categoría y el nombre de esa entrada. Las dos familias de rutas expresan pertenencias de negocio distintas, así que no basta con mirar el nombre del archivo para adivinar de qué objeto se trata.
Ese nombramiento también explica por qué el nombre del archivo cambia al renombrar una entrada. Cada vez que una entrada de la biblioteca de continuidad se guarda con imagen, se genera un nombre de archivo nuevo con la categoría actual y el nombre actual: primero se escribe el archivo nuevo y se guarda el registro con éxito, y solo después se elimina el archivo al que apuntaba la ruta anterior. Por eso renombrar una entrada no es solo cambiar un texto dentro de la base de datos; al guardar con imagen, el nombre del archivo en el disco también se vuelve a generar con el nombre actual.
Hay dos rutas de escritura que no dejan guardada la ruta autorizada
Al crear rápido una entrada de la biblioteca de continuidad y asociarla, el código actual escribe solo los datos de la imagen de la portada y no escribe la ruta del archivo de esa portada. Las fotos que llegan por proximidad tampoco escriben la ruta de la foto: escriben solo los datos de la imagen. Esos dos tipos de registro pueden seguir mostrando una imagen en la interfaz, pero la lógica de borrado no dispone de ninguna ruta autorizada persistida.
Lo que aquí se puede confirmar es “qué paso no escribió la ruta”. No se puede escribir después que “los archivos del disco se van acumulando seguro” ni que “hubo una fuga”: eso cae en la capa de los resultados y harían falta muestras del sistema de archivos y pruebas de borrado reales para sacar una conclusión.
Que falte la ruta es un hecho localizable en el código; qué queda al final en el disco es otra capa que todavía pide medición real.
El espejo de la base de datos y los archivos del espacio aislado tampoco están en la misma capa
Los datos de la imagen guardados en la base de datos pueden entrar en el espejo de datos del lado de la cuenta, mientras que el archivo al que apunta esa ruta local persistida no cae dentro del mismo alcance de ese espejo. Por eso no se puede escribir que “el registro de la base de datos apareció en otro dispositivo” sea lo mismo que “el archivo del espacio aislado al que apunta esa ruta ya apareció también”.
Todos estos archivos de medios están dentro del espacio aislado de la propia app, y no son recursos estáticos del paquete. Al borrar la app, los archivos locales del espacio aislado desaparecen junto con los datos de la app. Del otro lado, esto tampoco arma una promesa de “fotos recuperables desde la nube”, porque esta página solo describe la relación entre los datos de la base de datos y la ruta local, sin demostrar qué resulta al reinstalar o al cambiar de dispositivo.
El video se entiende aparte
Los registros de video localizan el archivo sobre todo por la ruta local, y al leerla existe una lógica de respaldo hacia la zona de llegada, para el caso de que la ruta del registro siga apuntando al lugar donde el archivo fue escrito. Ese camino no es el de las fotos, cuya muestra lee directo los datos de la imagen de la base de datos, así que no se puede trasladar tal cual a los videos el mecanismo de doble registro de las fotos.
Lo que esta página sí responde es por qué una misma foto tiene dos registros, uno de datos de la imagen y otro de ruta, quién lee cada uno, por qué el nombre del archivo cambia al renombrar y qué rutas de escritura no dejaron guardada la ruta autorizada. De aquí no se puede prometer ni una deduplicación automática, ni una recuperación entre dispositivos, ni que los archivos no se vayan a perder.
FAQ
¿Por qué la foto sigue mostrándose si al borrarla puede no haber una ruta utilizable?
Porque el lado que muestra lee los datos de la imagen de la base de datos, mientras que el lado que borra depende de la ruta relativa persistida. Los dos caminos leen registros distintos.
¿Renombrar una entrada de la biblioteca de continuidad cambia solo el texto?
Al guardar con imagen no cambia solo el texto. La implementación actual genera un nombre de archivo nuevo según la categoría y el nombre nuevos, y solo después de guardar con éxito se ocupa de la ruta anterior.
¿En qué fotos puede no haberse escrito la ruta?
En la portada creada rápido y asociada a una entrada de la biblioteca de continuidad, y en las fotos que llegan por proximidad: en los dos casos la ruta de escritura actual tiene situaciones donde escribe solo los datos de la imagen sin escribir la ruta autorizada.
¿Que la base de datos tenga la foto equivale a que el otro dispositivo tenga el archivo local?
No se puede inferir así. Los datos de la imagen en la base de datos y el archivo local del espacio aislado son capas distintas, y que exista el registro en la base de datos no prueba que el archivo local al que apunta esa ruta ya esté presente en otro dispositivo.
Axiom One LLC — SlateX. Las cifras de arriba son a fecha de 2026-09-24.