Perché una stessa foto di continuità ha due registrazioni, i dati dell'immagine e il percorso del file
Una foto di continuità, in SlateX, può esistere in due registrazioni di natura diversa: i dati dell'immagine salvati nel database e il percorso relativo che punta al file su disco dentro la sandbox dell'app. L'interfaccia legge i dati dell'immagine per mostrare, mentre l'eliminazione del file si appoggia al percorso relativo salvato. Le due registrazioni servono azioni diverse, quindi «l'immagine è ancora visibile» e «quel file su disco può essere trovato con precisione ed eliminato» non sono la stessa cosa.
I dati dell'immagine rispondono a «che cosa mostrare», il percorso del file risponde a «quale file eliminare»; le due registrazioni non si sostituiscono a vicenda.
La visualizzazione legge i dati dell'immagine, l'eliminazione riconosce il percorso relativo
Schede, dettaglio, area dei riferimenti associati e pagina di confronto leggono tutti la foto dai dati dell'immagine nel database, usando però formati di anteprima diversi a seconda delle interfacce. Significa che, finché i dati dell'immagine ci sono, l'interfaccia ha una propria fonte di visualizzazione e non deve prima riaprire quella foto seguendo il percorso su disco.
La logica di eliminazione fa l'opposto. Quando si elimina un materiale o un file della libreria continuità, il codice usa il percorso relativo persistito in precedenza per localizzare il file su disco e vieta esplicitamente di indovinare il nome del file dai campi del modello corrente. Senza un percorso preciso salvato, la logica di eliminazione non cerca «un file che sembra quello giusto» attraverso una scansione per nome.
È per questo che la stessa foto va capita insieme come «oggetto del database» e come «file nella sandbox». Che l'oggetto del database sia visualizzabile non equivale ad affermare che la posizione facente fede del file su disco sia registrata per intero, e che il percorso su disco esista non vuol dire che il lato visualizzazione dipenda da esso.
Le due famiglie di foto seguono denominazioni di cartelle diverse
I materiali di continuità agganciati a un record di ciak formano il percorso secondo la gerarchia progetto, scena, inquadratura e ciak; le copertine o i materiali di riferimento agganciati a una voce della libreria continuità prendono invece il nome di file dalla categoria e dal nome della voce. Le due famiglie di percorsi esprimono appartenenze operative diverse, e guardando soltanto il nome del file non si può capire a quale oggetto appartengano.
Questa denominazione spiega anche perché il nome del file cambi quando una voce cambia nome. Ogni salvataggio con immagine di una voce della libreria continuità genera un nome di file nuovo dalla categoria corrente e dal nome corrente, scrive prima il nuovo file, salva la registrazione e solo dopo elimina il file puntato dal vecchio percorso. Cambiare il nome di una voce non significa quindi modificare solo un'etichetta di testo nel database: con un salvataggio che include un'immagine, anche il nome del file su disco viene rigenerato dal nome corrente.
Due percorsi di scrittura non lasciano un percorso autoritativo
Quando si crea rapidamente una voce e la si aggancia alla libreria continuità, il codice attuale scrive solo i dati dell'immagine della copertina e non scrive il percorso del file della copertina. Anche le foto portate dentro dalla ricezione di prossimità scrivono solo i dati dell'immagine, senza scrivere il percorso della foto. Queste due categorie di registrazioni possono quindi continuare a mostrare un'immagine nell'interfaccia, ma la logica di eliminazione non ha un percorso autoritativo già persistito da usare.
Qui si può confermare «quale passo non ha scritto il percorso»; non si può spingere la frase fino a «quindi i file su disco si accumulano per forza» o «quindi c'è una perdita». Quello appartiene al livello dei risultati e richiederebbe campioni del file system e prove di eliminazione reali per essere concluso.
Che il percorso manchi è un fatto localizzabile nel codice; che cosa il disco alla fine trattenga è un altro livello, che va misurato.
Il mirror del database e i file nella sandbox non sono lo stesso livello
I dati dell'immagine salvati nel database possono entrare nel mirror dei dati lato account, mentre il file puntato da quel percorso locale persistito non sta nello stesso ambito di mirror. Non si può quindi scrivere «la registrazione del database compare su un altro dispositivo» come se fosse già comparso anche il file nella sandbox puntato da quel percorso.
Tutti questi file media stanno nella sandbox dell'app stessa, non fra le risorse statiche dentro il pacchetto dell'app. Quando l'app viene eliminata, i file locali nella sandbox spariscono insieme ai dati dell'app. D'altro canto questo non costituisce alcuna promessa di «foto recuperabili dal cloud», perché questa pagina descrive soltanto il rapporto fra i dati del database e il percorso locale e non dimostra che cosa accada al recupero dopo una reinstallazione o un cambio di dispositivo.
Perché il video va capito a parte
Le registrazioni video si appoggiano soprattutto al percorso locale per localizzare i file, e in lettura hanno una logica di ripiegamento sull'area di atterraggio, per il caso in cui il percorso nella registrazione punti ancora alla posizione dove il file era stato scritto. Il loro cammino è diverso da quello delle foto, che in visualizzazione leggono direttamente i dati dell'immagine del database, quindi il meccanismo di doppia scrittura delle foto non si può applicare tale e quale ai video.
Questa pagina può rispondere a perché una stessa foto abbia due registrazioni, i dati dell'immagine e il percorso, a chi legge quale delle due, a perché il cambio di nome generi un nome di file nuovo e a quali percorsi di scrittura non abbiano lasciato un percorso autoritativo. Non può promettere per questo una deduplicazione automatica, un recupero fra dispositivi o l'assenza di file persi.
FAQ
Perché la foto si vede ancora, ma all'eliminazione può non esserci un percorso utilizzabile?
Perché il lato visualizzazione legge i dati dell'immagine nel database, mentre il lato eliminazione dipende dal percorso relativo persistito. I due cammini leggono registrazioni diverse.
Rinominare una voce della libreria continuità cambia solo il testo?
Con un salvataggio che include un'immagine non cambia solo il testo. L'implementazione attuale genera un nome di file nuovo dalla categoria e dal nome correnti e, dopo il salvataggio riuscito, tratta il vecchio percorso.
Quali percorsi di foto possono non essere stati scritti?
La copertina creata con l'aggancio rapido a una voce della libreria continuità e le foto portate dentro dalla ricezione di prossimità: in entrambe le strade di scrittura attuale esiste il caso di scrivere solo i dati dell'immagine senza scrivere un percorso autoritativo.
Avere la foto nel database vuol dire avere il file locale corrispondente su un altro dispositivo?
Non si può dedurre così. I dati dell'immagine nel database e il file locale nella sandbox sono livelli diversi, e il file locale puntato dal percorso non risulta comparso su un altro dispositivo per il solo fatto che la registrazione del database esiste.
Axiom One LLC — SlateX. I numeri di questo articolo sono aggiornati al 2026-09-24.