Pourquoi une même photo de continuité porte deux relevés : les données d'image et le chemin du fichier
Une photo de continuité peut porter, dans SlateX, deux relevés de nature différente : les données d'image stockées dans la base de données, et le chemin relatif qui pointe vers le fichier sur le disque, dans le bac à sable de l'app. L'affichage à l'interface lit les données d'image, et la suppression du fichier dépend du chemin relatif déjà enregistré. Les deux servent des actions différentes, et « l'image s'affiche encore » et « ce fichier sur le disque est retrouvé et supprimé précisément » ne sont pas la même chose.
Les données d'image répondent à « quoi afficher », le chemin du fichier répond à « quel fichier supprimer » ; les deux relevés ne se remplacent pas l'un l'autre.
L'affichage lit les données d'image, la suppression suit le chemin relatif
Les fiches, les écrans de détail, la zone des références associées et l'écran de comparaison lisent tous la photo dans les données d'image de la base de données, avec seulement une taille de vignette différente selon l'écran. Autrement dit, tant que les données d'image sont là, l'interface a sa propre source d'affichage, et elle n'a pas besoin de rouvrir d'abord le fichier sur le disque en suivant un chemin.
La logique de suppression fait exactement l'inverse. Quand on supprime un média ou un fichier de la bibliothèque de continuité, le code se sert du chemin relatif persisté précédemment pour localiser le fichier sur le disque, et il interdit explicitement de redeviner un nom de fichier à partir des champs du modèle courant. Sans chemin exact enregistré, la suppression ne va pas, par un balayage de noms, « chercher un fichier qui y ressemble ».
C'est pourquoi une même photo doit être comprise à la fois comme un « objet de la base de données » et comme un « fichier du bac à sable ». Qu'un objet de base de données s'affiche ne veut pas dire que la position faisant autorité du fichier sur le disque est complètement enregistrée ; et la présence d'un chemin de disque ne veut pas dire que l'affichage dépend de lui en retour.
Les deux sortes de photos ne suivent pas la même nommage de répertoires
Les médias de continuité rattachés à une fiche de prise forment leur chemin selon l'étage projet, scène, plan et prise ; les images de couverture ou les médias de référence rattachés à une entrée de la bibliothèque de continuité, eux, forment leur nom de fichier d'après la catégorie et le nom de l'entrée. Les deux familles de chemins expriment deux rattachements métier distincts, et on ne peut pas deviner l'objet concerné en regardant seulement le nom du fichier.
Ce nommage explique aussi pourquoi renommer une entrée change le nom du fichier. Pour une entrée de la bibliothèque de continuité, chaque enregistrement avec image génère un nouveau nom de fichier d'après la catégorie courante et le nom courant : le nouveau fichier est écrit et l'enregistrement sauvegardé d'abord, puis le fichier pointé par l'ancien chemin est supprimé. Renommer une entrée ne modifie donc pas une simple étiquette de texte dans la base de données, puisque, à l'enregistrement avec image, le nom du fichier sur le disque est lui aussi régénéré selon le nom courant.
Deux chemins d'écriture ne laissent aucun chemin faisant autorité
Quand on crée rapidement une entrée de la bibliothèque de continuité et qu'on la rattache, le code actuel écrit seulement les données d'image de la couverture, sans écrire le chemin du fichier de couverture. Les photos reçues par réception de proximité, elles non plus, n'écrivent que les données d'image, sans le chemin de la photo. Ces deux sortes de relevés peuvent donc continuer à montrer une image à l'interface, sans qu'aucun chemin faisant autorité persisté soit disponible pour la suppression.
Ce que l'on peut établir ici est « quelle étape n'a pas écrit le chemin ». Il ne faut pas pousser jusqu'à « donc les fichiers du disque s'accumulent forcément » ou « donc une fuite se produit ». Cela relève du résultat, et exigerait des échantillons du système de fichiers et de vrais tests de suppression pour être conclu.
Un chemin non écrit est un fait de code établissable ; ce que le disque garde à la fin est une autre couche, qui demande une mesure réelle.
Le miroir de la base de données et les fichiers du bac à sable ne sont pas la même couche
Les données d'image stockées dans la base de données peuvent entrer dans le miroir des données côté compte, alors que le fichier lui-même, pointé par le chemin local persisté, n'est pas dans le même périmètre de miroir. On ne peut donc pas écrire « l'enregistrement de base de données est apparu sur un autre appareil » comme si « le fichier du bac à sable pointé par ce chemin y est aussi apparu ».
Tous ces fichiers médias sont dans le bac à sable de l'app elle-même, et non parmi les ressources statiques du paquet de l'app. Quand on retire l'app, les fichiers locaux du bac à sable disparaissent avec les données de l'app. Pour autant, cela ne constitue aucune promesse de « photos récupérables depuis le nuage » : cette page décrit seulement le rapport entre les données de la base de données et le chemin local, et ne prouve pas le résultat d'une restauration après réinstallation ou changement d'appareil.
La vidéo demande une lecture à part
Les enregistrements vidéo localisent leur fichier principalement par le chemin local, et la lecture comporte une logique de repli sur la zone de dépôt, pour le cas où le chemin enregistré pointe encore vers l'endroit où le fichier a été écrit. Ce chemin est différent de celui des photos, dont l'affichage lit directement les données d'image de la base de données, et on ne peut donc pas transposer le mécanisme de double écriture des photos aux vidéos.
Ce que cette page peut répondre : pourquoi une même photo porte deux relevés, données d'image et chemin ; qui lit lequel ; pourquoi le nom du fichier change quand on renomme ; et quels chemins d'écriture ne laissent aucun chemin faisant autorité. Elle ne permet pas de promettre une déduplication automatique, une restauration entre appareils, ou l'absence de perte de fichiers.
FAQ
Pourquoi la photo s'affiche-t-elle encore alors qu'aucun chemin n'est disponible à la suppression ?
Parce que le côté affichage lit les données d'image de la base de données, tandis que le côté suppression dépend du chemin relatif persisté. Les deux chaînes lisent des relevés différents.
Renommer une entrée de la bibliothèque de continuité ne change-t-il que le texte ?
Non, pas quand l'enregistrement se fait avec une image. L'implémentation actuelle génère un nouveau nom de fichier d'après la catégorie et le nom nouveaux, puis traite l'ancien chemin une fois la sauvegarde réussie.
Quels chemins de photos risquent de ne pas être écrits ?
L'image de couverture créée rapidement puis rattachée à une entrée de la bibliothèque de continuité, et les photos reçues par réception de proximité : les deux chemins d'écriture actuels peuvent n'écrire que les données d'image, sans le chemin faisant autorité.
Une photo présente dans la base de données vaut-elle un fichier local correspondant sur un autre appareil ?
On ne peut pas le déduire ainsi. Les données d'image de la base de données et le fichier local du bac à sable sont deux couches différentes, et le fichier local pointé par un chemin n'est pas prêté apparu sur un autre appareil du seul fait que l'enregistrement de base de données existe.
Axiom One LLC — SlateX. Chiffres arrêtés au 2026-09-24.