Why a Handoff Cannot Hand Back a Path to the Media
ALE, CSV, PDF and FDX all exchange structured records, and none of them can hand over a path that resolves to media on the receiver’s own machine. Both machine-readable files carry a file-name cell and a path cell, but not under the same column names: the CSV uses Source File Name and Source File Path, the ALE uses Source File Name and Source File. The CSV writes out whatever path the record holds, while the ALE pair ships only when the whole string is ASCII, so non-Latin text leaves those cells empty. The values come from what the script supervisor transcribed on set, or, where media were imported from a file, from the address recorded on that machine; where neither happened the cell ships empty. PDF and FDX carry neither cell.
Media does sit somewhere in the project store; a filled cell in a handoff names a location on the sending machine, and a receiver cannot reconnect its own media from it.
An address in a handoff belongs to the sender, and where media sit on this machine is another thing
How the app stores media on the device is its own business. What matters here is that a path inside a handoff belongs to the sending machine, not to a pointer the receiver can resolve. When ALE, CSV, PDF, or FDX is generated, it carries take records and related fields rather than a manifest of where the receiver’s media live. A receiver may therefore see reel, scene, or take identifiers without receiving the physical local-file location that was used by the originating project. A shot identifier is a separate column only in CSV and PDF; an ALE has no shot column.
Why a file name is not a substitute for the original path
The file name on disk can already differ from the name it arrived with, so it cannot tell you where the material came from.
Photos come from two sources: images captured on set or taken with the quick-capture path, and photos chosen from the library or imported from a file. Neither case carries the original path. Even if the receiver happens to see a similar file name elsewhere, that is not proof of an “original file name plus original bytes” relationship; the name in the handoff is assembled from the reel and clip values, not the name on disk. How media are normalized stays on this device; a path written into a handoff column names that device’s directory, not the receiver’s copy.
“The path in a handoff cannot be opened on the receiving machine” describes the boundary of an exchange; it does not make a claim about whether the media exists inside the originating project store.
Why this directly limits media reconnection
A path written in a handoff points into the sender’s directory, so the receiver still lacks a physical pointer that takes a record row directly to a particular file location on its own machine. Reel, scene, and take identifiers can still help establish identity, but identifiers are not paths. The receiver has to relate those identifiers to its own media manifest, file names, and actual directory contents.
This is the physical reason the article What to Check Before Using an ALE for Matching asks the receiver to return to the media and the on-set record. A file can open cleanly and expose readable columns without carrying media locations at the same time. If a receiving workflow needs a direct record-to-media relationship, that relationship has to be supplied from the media information available on the receiving side.
Where all four handoffs run into the same boundary
ALE and CSV are machine-readable tables, PDF is a human-readable summary, and FDX is used for script exchange. ALE and CSV draw on the same take records and both carry a file-name cell and a path cell, though not under the same names — Source File Name and Source File Path in the CSV, Source File Name and Source File in the ALE: the CSV writes the stored value out verbatim, the ALE pair accepts ASCII only, and the values come either from on-set transcription or from the address recorded when media were imported from a file — with neither, the cell is empty. The PDF exists for reading, and FDX works from script-side content that carries no take records at all. None of the four contains an address the receiver can resolve to its own media, and format differences do not change that boundary. More columns do not turn that address into one the receiver can open.
For example, What a CSV Handoff Carries That an ALE Does Not is about differences in field sets, not about a path appearing from nowhere; What to Check Before Using an ALE for Matching walks through which cells ship empty when nobody transcribed them and how the reconcile sheet flags them; Missing Values in a Handoff: What Each Blank Means separates the layer under that blank — an empty string, a dash placeholder, a generated default number and an all-zero timecode each arrive for a different reason. Receiving should keep three things apart: a cell that was never filled in, a cell that holds transcribed text, and a pointer that could actually reconnect media. A name sitting in a column is not a location. Where the four handoffs are saved and how long they last is covered in Where Handoff Files Live After Export—and How Long They Last.
How the receiver should build the media relationship
When a handoff record needs to be related to media, the receiver should start with visible identifiers such as reel, scene, and take and check them against its own media manifest. If media-side naming, reel values, or directory organization do not agree with the handoff record, the actual media and on-set record should be used to resolve the discrepancy rather than guessing a path. The handoff itself does not provide the direct reconnection pointer.
These files should therefore be understood as record and exchange data rather than a media manifest or media backup. What they give is a string from the sending side, not a resolvable pointer from a record to media on the receiver’s machine, and they promise no automatic media linking inside a receiving project. The receiver should verify reel, scene, and take identifiers against its own media manifest.
FAQ
Why does a filled path cell still not reconnect the media?
A file name is an identity clue inside a record; a path is where the media actually sits — not the same thing. ALE and CSV each carry those two cells under different names — Source File Name and Source File Path in the CSV, Source File Name and Source File in the ALE: the CSV writes the stored value out verbatim, the ALE pair accepts ASCII only, so non-Latin text leaves those cells empty. PDF and FDX carry neither. The values come either from on-set transcription or from the address recorded on import, and either way they name the shooting side’s files, not the receiver’s directory, so a filled cell never reconstructs a location the receiver can open.
Can the handoff give me back the original photo file?
Not from the handoff alone. The handoff carries a file name assembled from the reel and clip values, not the photo’s original path, and it does not promise a byte-for-byte match with the original file.
Does CSV gain a resolvable path because it carries more fields?
More columns do not hand the receiver a resolvable location. The CSV writes out whatever the record holds — transcribed on set or recorded when media were imported from a file — the matching ALE cells accept ASCII only, and PDF and FDX have neither column at all. A filled cell still names the sender’s directory.
What should be used when media must be reconnected?
The receiver should verify visible identifiers such as reel, scene, and take against its own media manifest and actual files. A path a handoff carries belongs to the sending machine and must not be read as an address on the receiver’s own disk.
Axiom One LLC — SlateX