Why One Continuity Photo Has Both Image Data and a File Path

A continuity photo in SlateX can have two different kinds of records: image data stored in the database and a relative path pointing to a file inside the app sandbox. The UI displays the image from the database data, while file deletion relies on the persisted path. Those records support different operations, so “the image can still be displayed” and “the exact disk file can be found and deleted” are not the same fact.

Image data answers “what can be displayed”; the path answers “which file should be deleted.” They are not substitutes for each other.

Display reads image data; deletion uses the stored path

Cards, detail views, reference rows, and comparison views all read the photo from database image data, with different thumbnail sizes for different surfaces. The UI therefore has a display source without first reopening the image through its filesystem path.

Deletion works in the opposite direction. When media or continuity-library files are removed, the code uses the previously persisted relative path. It explicitly avoids reconstructing a filename from the current model and does not scan for a similarly named file when no exact path has been stored.

That is why one photo has to be understood as both a database object and a sandbox file. The database object can remain displayable even when the file-location record is incomplete, while a path record does not become the display source merely because it exists.

The two photo families use different directory naming

Media attached to a take uses a hierarchy based on project, scene, shot, and take. Continuity-library items use a separate naming family based on category and item name. The path itself therefore reflects the business object it belongs to rather than being a generic photo filename.

This also explains why renaming a continuity item can change the disk filename. When an item with an image is saved, the current category and current name are used to generate a new filename. The new file is written and the record is saved before the old path is removed. Renaming is therefore not merely a text-label change when an image is being saved.

Two write paths do not persist the authoritative path

A quick-create-and-link path for a continuity item writes cover image data without writing the cover-image path. Nearby-received photos likewise write image data without writing an image path. Those records can still display an image, but the deletion logic does not have a persisted authoritative path for that file.

The supported claim stops at identifying the missing path write. It does not establish that files necessarily accumulate or that a leak occurs. Those are filesystem outcomes that would require runtime samples and deletion testing.

A missing path write is a code fact; the final filesystem residue is a separate result that needs runtime verification.

Database mirroring and sandbox files are different layers

The image data stored in the database can participate in account-side database mirroring, while the local file referenced by the persisted path is not mirrored as that same filesystem object. A database record appearing on another device therefore does not prove that the corresponding sandbox file has arrived there.

These media files are app-sandbox data rather than static resources in the app bundle, so removing the app removes that local sandbox data. That still does not create a promise that a photo can later be restored from the cloud; this page describes storage relationships, not reinstall or cross-device recovery behavior.

Video needs a separate model

Video is located primarily through a local path, with fallback location resolution when the stored path reflects an earlier landing location. That is different from the photo display path, which reads image data directly from the database. The photo dual-record model should therefore not be generalized to video.

This page can explain why a photo has image data and a path, which operation reads each record, why renaming can change filenames, and which write paths omit the authoritative path. It does not support promises about automatic deduplication, cross-device restoration, or media never being lost.

FAQ

Why can a photo display even when deletion has no usable path?

Because the display path reads database image data, while deletion relies on the persisted relative file path. They are separate records used by separate code paths.

Does renaming a continuity-library item change only its text label?

Not when the item is saved with an image. The current category and name are used to generate a new filename, and the old path is handled after the new save succeeds.

Which photo paths may not be persisted?

The quick-create-and-link cover path and the nearby-received photo path currently have write flows that store image data without storing the authoritative file path.

Does a photo record in the database prove the local file exists on another device?

No. Database image data and the local sandbox file are different layers, so the presence of the record does not prove that the path’s file exists on another device.

Axiom One LLC — SlateX. Figures current as of 24 September 2026.