Por que uma mesma foto de continuidade tem dois registros: o dado da imagem e o caminho do arquivo
Uma foto de continuidade pode ter, ao mesmo tempo, dois registros de natureza diferente no SlateX: os dados da imagem dentro do banco de dados e o caminho relativo que aponta para um arquivo no disco, dentro do sandbox do app. A exibição na interface lê os dados da imagem, e a exclusão do arquivo depende do caminho relativo que foi persistido. Os dois servem a ações diferentes, e por isso “a imagem ainda aparece na tela” e “aquele arquivo no disco pode ser encontrado com precisão e excluído” não são a mesma coisa.
Os dados da imagem respondem “o que exibir”, e o caminho do arquivo responde “qual arquivo excluir”; os dois registros não substituem um ao outro.
A exibição lê os dados da imagem, a exclusão obedece ao caminho relativo
Cartões, tela de detalhe, área de referência e interface de comparação leem a foto dos dados de imagem guardados no banco de dados, apenas com tamanhos de miniatura diferentes conforme a interface. Quer dizer: enquanto os dados da imagem estiverem lá, a interface tem fonte própria para exibir, e não precisa primeiro reabrir aquela foto seguindo o caminho do disco.
A lógica de exclusão faz exatamente o contrário. Ao excluir mídia ou um arquivo da biblioteca de continuidade, o código usa o caminho relativo persistido anteriormente para localizar o arquivo no disco, e proíbe expressamente adivinhar o nome do arquivo a partir dos campos do modelo atual. Sem um caminho exato que tenha sido salvo, a exclusão não sai varrendo nomes atrás de “um arquivo que pareça com ele”.
É por isso que a mesma foto precisa ser entendida, em paralelo, como “objeto do banco de dados” e como “arquivo no sandbox”. Que o objeto do banco de dados seja exibível não equivale a dizer que a posição autoritativa do arquivo no disco foi registrada por completo; e que o caminho exista no disco não significa que a exibição passe a depender dele.
Os dois tipos de foto usam nomes de diretório diferentes
A mídia de continuidade pendurada no registro de tomada forma o caminho pela hierarquia de projeto, cena, plano e tomada; a capa ou a mídia de referência pendurada numa entrada da biblioteca de continuidade forma o nome do arquivo pela categoria e pelo nome da entrada daquela biblioteca. As duas famílias de caminho expressam pertencimentos de negócio diferentes, e não se deve adivinhar a que objeto algo pertence olhando só o nome do arquivo.
Essa nomeação também explica por que o nome do arquivo muda quando a entrada é renomeada. Cada salvamento com imagem de uma entrada da biblioteca de continuidade gera um nome de arquivo novo a partir da categoria atual e do nome atual, grava o arquivo novo, salva o registro com sucesso e só depois apaga o arquivo para o qual o caminho antigo apontava. Renomear uma entrada, portanto, não é mexer só num rótulo de texto dentro do banco de dados: ao salvar com imagem, o nome do arquivo no disco também é regenerado conforme o nome atual.
Dois caminhos de escrita não deixam um caminho autoritativo
Ao criar rapidamente uma entrada da biblioteca de continuidade e vinculá-la, o código atual grava só os dados da imagem de capa, sem gravar o caminho do arquivo de capa. Fotos recebidas por proximidade também gravam só os dados da imagem, sem gravar o caminho da foto. Esses dois tipos de registro continuam podendo exibir imagem na interface, mas a lógica de exclusão fica sem um caminho autoritativo persistido para usar.
O que se pode confirmar aqui é “em qual passo o caminho não foi escrito”. Não se pode continuar escrevendo que “então os arquivos do disco necessariamente se acumulam” nem que “está havendo um vazamento”. Isso pertence ao plano do resultado e exigiria amostras do sistema de arquivos e testes reais de exclusão para virar conclusão.
A ausência do caminho é um fato de código localizável; o que o disco acaba guardando é outra camada, que precisa ser medida.
O espelho do banco de dados e os arquivos do sandbox também não são a mesma camada
Os dados de imagem guardados no banco de dados podem entrar no espelho de dados do lado da conta, enquanto o arquivo apontado por aquele caminho local persistido não está na mesma faixa de espelhamento. Por isso não se pode escrever que “o registro do banco de dados apareceu em outro aparelho” equivale a “o arquivo do sandbox para o qual aquele caminho aponta também já apareceu lá”.
Todos esses arquivos de mídia ficam no sandbox do próprio app, e não como recursos estáticos dentro do pacote do app. Ao remover o app, os arquivos locais do sandbox desaparecem junto com os dados do app. Isso também não constitui promessa de “foto recuperável pela nuvem”, porque este texto só descreve a relação entre os dados do banco de dados e o caminho local, e não comprova o resultado de uma reinstalação ou da troca de aparelho.
Por que o vídeo precisa de um entendimento à parte
O registro de vídeo depende principalmente do caminho local para localizar o arquivo, e a leitura tem uma lógica de reserva na área de recebimento, para o caso de o caminho no registro ainda apontar para o lugar onde o arquivo foi escrito. O caminho dele é diferente do das fotos, que leem os dados de imagem direto do banco de dados na exibição, e por isso o mecanismo de dupla gravação das fotos não pode ser aplicado ao vídeo sem mais.
O que este texto responde é: por que a mesma foto tem dois registros, dados da imagem e caminho; quem lê cada um deles; por que o nome do arquivo muda ao renomear; e que caminhos de escrita não deixaram um caminho autoritativo. Ele não pode, a partir daí, prometer deduplicação automática, recuperação entre aparelhos nem que arquivo algum se perde.
FAQ
Por que a foto ainda aparece, mas pode não haver caminho utilizável na exclusão?
Porque a exibição lê os dados de imagem do banco de dados, e a exclusão depende do caminho relativo persistido. As duas cadeias leem registros diferentes.
Renomear uma entrada da biblioteca de continuidade mexe só no texto?
Ao salvar com imagem, não mexe só no texto. A implementação atual gera um nome de arquivo novo conforme a categoria e o nome novos e só trata o caminho antigo depois que a gravação deu certo.
Quais caminhos de foto podem acabar não sendo escritos?
A capa criada rapidamente e vinculada a uma entrada da biblioteca de continuidade, e as fotos recebidas por proximidade: nos dois casos o caminho de escrita atual tem situações em que grava só os dados da imagem, sem gravar o caminho autoritativo.
Ter a foto no banco de dados quer dizer que o outro aparelho tem o arquivo local correspondente?
Não se pode inferir isso. Os dados de imagem do banco de dados e o arquivo local no sandbox são camadas diferentes, e a existência do registro no banco de dados não prova que o arquivo local para o qual o caminho aponta tenha aparecido em outro aparelho.
Axiom One LLC — SlateX. Os números acima são os de 2026-09-24.