Warum ein und dasselbe Continuity-Foto als Bilddatensatz und als Dateipfad geführt wird

Zu einem Continuity-Foto können in SlateX zwei Aufzeichnungen verschiedener Art gleichzeitig existieren: die Bilddaten in der Datenbank und der relative Pfad, der auf eine Datendatei auf dem Gerät in der App-Sandbox zeigt. Die Oberfläche zeigt das Bild aus den Bilddaten, und beim Löschen einer Datei zählt der gespeicherte relative Pfad. Beide dienen verschiedenen Handlungen, deshalb sind „das Bild ist noch zu sehen“ und „die Datei auf der Platte lässt sich exakt finden und löschen“ nicht dieselbe Sache.

Die Bilddaten beantworten „was angezeigt wird“, der Dateipfad beantwortet „welche Datei gelöscht wird“; die beiden Aufzeichnungen ersetzen einander nicht.

Anzeigen liest Bilddaten, Löschen folgt dem relativen Pfad

Karte, Detailansicht, Referenzbereich und Vergleichsansicht lesen das Foto aus den Bilddaten in der Datenbank und nutzen dabei je Oberfläche eine andere Miniaturgröße. Solange die Bilddaten vorhanden sind, hat die Oberfläche also eine eigene Anzeigequelle und muss dafür nicht zuerst über den Pfad auf der Platte das Foto erneut öffnen.

Die Löschlogik arbeitet umgekehrt. Beim Löschen von Material oder einer Datei aus der Continuity-Bibliothek nutzt der Code den zuvor gespeicherten relativen Pfad, um die Datei auf der Platte zu finden, und schließt ausdrücklich aus, aus den aktuellen Modellfeldern einen Dateinamen zu rekonstruieren. Ohne eine gespeicherte exakte Pfadangabe sucht die Löschlogik auch nicht per Namensabgleich nach „einer Datei, die ähnlich aussieht“.

Deshalb ist dasselbe Foto als „Datenbankobjekt“ und als „Datei in der Sandbox“ zugleich zu verstehen. Dass das Datenbankobjekt anzeigbar ist, heißt nicht, dass die maßgebliche Position der Datei auf der Platte vollständig erfasst wäre; und dass ein Pfad auf der Platte existiert, heißt nicht, dass die Anzeigeseite umgekehrt davon abhängt.

Zwei Fotoarten folgen zwei verschiedenen Namensregeln

Continuity-Material an einer Take-Aufzeichnung baut seinen Pfad über die Ebene Projekt, Szene, Einstellung und Take; das Cover oder Referenzmaterial an einem Eintrag der Continuity-Bibliothek bildet seinen Dateinamen über Kategorie und Eintragname der Bibliothek. Die beiden Pfadfamilien drücken verschiedene inhaltliche Zugehörigkeiten aus, deshalb sollte nicht allein am Dateinamen geraten werden, zu welchem Objekt sie gehört.

Diese Benennung erklärt auch, warum beim Umbenennen eines Eintrags der Dateiname sich ändert. Jedes Speichern eines Eintrags mit Bild erzeugt aus der aktuellen Kategorie und dem aktuellen Namen einen neuen Dateinamen, schreibt zuerst die neue Datei, speichert den Datensatz, und erst danach wird die Datei am alten Pfad behandelt. Ein Umbenennen des Eintrags ist damit keine reine Textänderung in der Datenbank: Beim Speichern mit Bild wird der Dateiname auf der Platte nach dem aktuellen Namen neu erzeugt.

Zwei Schreibwege hinterlassen keinen maßgeblichen Pfad

Beim schnellen Anlegen und Verknüpfen eines Eintrags in der Continuity-Bibliothek schreibt der aktuelle Code nur die Bilddaten des Covers, nicht den Pfad der Coverdatei. Auch Fotos, die über die Nahbereichsübernahme hereinkommen, bekommen nur die Bilddaten, nicht den Fotopfad. Diese beiden Arten von Datensätzen können in der Oberfläche weiterhin ein Bild zeigen, ohne dass die Löschlogik eine gespeicherte maßgebliche Pfadangabe hätte.

Bestätigbar ist hier „an welcher Stelle kein Pfad geschrieben wurde“, und nicht weiter auszubauen zu „die Datei auf der Platte bleibt also sicher liegen“ oder „hier findet ein Leck statt“. Das gehört in die Ergebnisebene und braucht Dateisystemproben und tatsächliche Löschtests, um daraus einen Schluss zu ziehen.

Ein fehlender Pfad ist ein Code-Fakt auf der Ebene des Auffindens; was auf der Platte am Ende liegt, ist eine andere Ebene, die praktisch geprüft werden muss.

Datenabbild in der Datenbank und Datei in der Sandbox sind nicht dieselbe Ebene

Die Bilddaten in der Datenbank können in das Datenabbild der Kontoseite gelangen, während die Datei selbst, auf die der gespeicherte lokale Pfad zeigt, nicht in derselben Abbildreichweite liegt. Deshalb darf aus „der Datensatz erscheint auf einem anderen Gerät“ nicht gefolgert werden, „die Datei in der Sandbox an diesem Pfad ist dort auch angekommen“.

Alle diese Mediendateien liegen in der Sandbox der App selbst und nicht in statischen Ressourcen des App-Pakets. Wird die App entfernt, verschwinden die lokalen Dateien in der Sandbox zusammen mit den App-Daten. Dagegen folgt daraus auch kein Versprechen „über die Cloud wiederherstellbare Fotos“, denn diese Seite beschreibt nur das Verhältnis von Datenbankdaten zu lokalem Pfad und belegt kein Wiederherstellungsergebnis nach Neuinstallation oder Gerätewechsel.

Warum Videos noch einmal getrennt zu lesen sind

Video-Datensätze stützen sich beim Finden der Datei vor allem auf den lokalen Pfad, und beim Lesen gibt es eine Rückfalllogik auf den Ablageort, damit die Lage abgedeckt bleibt, in der der gespeicherte Pfad noch auf den Ort beim Schreiben der Datei zeigt. Das läuft anders als beim Foto, dessen Anzeige unmittelbar die Bilddaten der Datenbank liest, weshalb der Doppelmechanismus der Fotos nicht ohne Weiteres auf Videos übertragen werden kann.

Was diese Seite beantwortet: Warum ein Foto als Bilddaten und als Pfad doppelt geführt wird, wer welche der beiden Aufzeichnungen liest, warum beim Umbenennen ein neuer Dateiname entsteht, und an welchen Schreibwegen der maßgebliche Pfad fehlt. Daraus lässt sich keine automatische Duplikatentfernung, keine geräteübergreifende Wiederherstellung und keine Zusage ableiten, dass keine Datei verloren geht.

FAQ

Warum zeigt die Oberfläche das Foto noch, obwohl beim Löschen der Pfad fehlen kann?

Weil die Anzeigeseite die Bilddaten in der Datenbank liest und die Löschseite den gespeicherten relativen Pfad braucht. Die beiden Wege lesen verschiedene Aufzeichnungen.

Ändert das Umbenennen eines Eintrags in der Continuity-Bibliothek nur Text?

Beim Speichern mit Bild nicht. Die aktuelle Umsetzung erzeugt aus der neuen Kategorie und dem neuen Namen einen neuen Dateinamen und bearbeitet nach erfolgreichem Speichern den alten Pfad.

Bei welchen Fotos bleibt der Pfad möglicherweise ungeschrieben?

Beim Cover, das über die schnelle Anlage mit einem Eintrag der Continuity-Bibliothek verknüpft wird, und bei Fotos aus der Nahbereichsübernahme: Auf beiden Schreibwegen gibt es den Fall, dass nur Bilddaten und kein maßgeblicher Pfad geschrieben werden.

Heißt ein Foto in der Datenbank, dass auf einem anderen Gerät dieselbe lokale Datei liegt?

So lässt es sich nicht schließen. Bilddaten in der Datenbank und lokale Datei in der Sandbox sind verschiedene Ebenen, und die Datei an einem Pfad ist nicht dadurch belegt, dass der Datenbankdatensatz auf einem anderen Gerät erschienen ist.

Axiom One LLC — SlateX. Die obigen Zahlen Stand 2026-09-24.