同じコンティニュイティ写真に画像データとファイルパスの 2 種類の記録があるのはなぜか

1 枚のコンティニュイティ写真は、SlateX では性質の違う 2 種類の記録を同時に持ち得ます。データベースの中の画像データと、アプリのサンドボックス内にあるディスク上のファイルを指す相対パスです。インターフェースの表示が読み取るのは画像データで、ファイルを消すときに頼るのは保存済みの相対パスです。両者は別の動作に奉仕しているので、「画面にまだ見えている」と「ディスク上のそのファイルを正確に見つけて削除できる」は同じ話ではありません。

画像データは「何を表示するか」に答え、ファイルパスは「どのファイルを消すか」に答えます。2 種類の記録は互いに代われません。

表示は画像データを読み、削除は相対パスを頼る

カード、詳細、関連参照エリア、比較ページはいずれもデータベースの中の画像データから写真を読み取ります。違うインターフェースで別のサムネイル規格を使うだけです。つまり、画像データが残っている限り、インターフェースには自分の表示元があるのであって、まずディスクのパスをたどってその写真を開き直す必要はありません。

削除のロジックはちょうど逆です。素材またはコンティニュイティライブラリのファイルを消すとき、コードは先に永続化しておいた相対パスでディスク上のファイルを特定し、現在のモデルのフィールドからファイル名を推測し直すことを明確に禁じています。保存された正確なパスが 1 本もないとき、削除のロジックは名前の検索で「それらしく見える」ファイルを探すことはしません。

だから同じ 1 枚の写真を「データベースのオブジェクト」と「サンドボックス内のファイル」の両方として理解する必要があります。データベースのオブジェクトが表示できることは、ディスク上のファイルの正本となる位置まで記録し終えていることを意味しません。ディスクのパスが存在することも、表示側がそれを逆に頼ることを意味しません。

2 種類の写真は違うディレクトリの命名を歩く

テイク記録に紐付いたコンティニュイティ素材は、プロジェクト・シーン・ショット・テイクという階層でパスを作ります。コンティニュイティライブラリの項目に紐付いたカバーまたは関連素材は、ライブラリのカテゴリと項目名でファイル名を作ります。2 つのパス族が表しているのは業務上の帰属のちがいであって、ファイル名だけを見てどのオブジェクトに属するかを推測することはできません。

この命名は、項目の名前を変えたときにファイル名も変わる理由を同時に説明します。コンティニュイティライブラリの項目は、写真付きで保存するたびに現在のカテゴリと現在の名前で作った新しいファイル名を使い、先に新しいファイルを書いて記録の保存が成功したあとで、古いパスが指していたファイルを消します。したがって項目の名前を変えることは、データベースの中の文字ラベルだけ書き換える操作ではありません。写真付きで保存すれば、ディスク上のファイル名も現在の名前に従って再生成されます。

2 本の書き込み経路は正本となるパスを残さない

コンティニュイティライブラリの項目をその場で新規作成して関連付けるとき、現在のコードはカバーの画像データだけを書いて、カバーのファイルパスは書きません。ローカルネットワークで受け取った写真も、画像データだけを書いて写真のパスは書きません。そのため、この 2 種類の記録でもインターフェース上は写真を表示できますが、削除のロジックには永続化済みの正本となるパスが 1 本もありません。

ここで確認できるのは「どのステップがパスを書かなかったか」であって、それを続けて「だからディスク上のファイルが必ず積み上がる」や「だから漏洩が起きた」と書き換えることはできません。あれは結果側の話で、ファイルシステムのサンプルと実際の削除テストまで必要です。

パスの欠落は特定できるコードの事実です。ディスクに最終的に何が残留するかは、実測を要する別の層の話です。

データベースのミラーとサンドボックスのファイルも同じ層ではない

データベースに保存された画像データはアカウント側のデータミラーに入れますが、あの永続化されたローカルファイルのパスが指しているファイルそのものは、同じミラーの範囲に入っていません。したがって、「データベースの記録が別のデバイスに現れた」を「そのパスが指すサンドボックス内のファイルも現れた」と書くことはできません。

これらのメディアファイルはすべてアプリ自身のサンドボックスにあって、App 同梱の静的リソースではありません。アプリを削除すれば、サンドボックス内のローカルファイルはアプリのデータといっしょに消えます。一方で、それが「クラウドから写真を復元できる」ことの約束になるわけでもありません。本稿が説明するのはデータベースのデータとローカルのパスの関係だけで、再インストールや機種変更のあとの復元結果までは証明しないからです。

動画はなぜさらに分けて理解するのか

動画の記録はファイルを特定するのにローカルのパスを主に頼り、読み取り時には受け入れ領域へ戻るフォールバックがあります。記録の中のパスが、ファイルを書き込んだ当時の位置をまだ指している場合に対応するためです。動画は写真の「表示が直接にデータベースの画像データを読む」という経路とは違うので、写真の二重書き込みの仕組みをそのまま動画へ当てはめることはできません。

本稿が答えられるのは、同じ 1 枚の写真に画像データとパスの 2 種類の記録がある理由、どちらを誰が読むか、名前を変えたときになぜファイル名も変わるか、どの書き込み経路が正本となるパスを残さないか、までです。自動の重複排除、デバイスをまたぐ復元、ファイルが失われないことまでは、ここから約束できません。

FAQ

写真が表示できるのに、削除のときに使えるパスが無いのはなぜですか？

表示側が読むのはデータベースの中の画像データで、削除側が頼るのは永続化された相対パスだからです。2 本の経路が読んでいるのは別の記録です。

コンティニュイティライブラリの項目名を変えると、文字だけの変更になりますか？

写真付きで保存するなら文字だけにはなりません。現在の実装は新しいカテゴリと名前で作った新しいファイル名を使い、保存が成功してから古いパスを処理します。

どの写真のパスが書き込まれない場合がありますか？

コンティニュイティライブラリの項目をその場で新規作成して関連付ける場合のカバー、およびローカルネットワークで受け取った写真です。現在の書き込み経路には、画像データだけを書いて正本となるパスを残さないケースがどちらも存在します。

データベースに写真があれば、別のデバイスにも対応するローカルファイルがありますか？

そうは推測できません。データベースの画像データとローカルのサンドボックスファイルは別の層で、パスが指すローカルファイルはデータベースの記録があることをもって別のデバイスに現れたと証明されません。

Axiom One LLC — SlateX。上の数字は 2026-09-24 時点のものです。