Importing runs
Take a .glab file recorded on another installation into this archive as an independent, fully traceable entry: what is validated, what the copy gets, and what it never gets.
The Import control sits in the head of the run list, beside Refresh, and accepts one
.glab file recorded on another installation (Exporting a run).
The control is drawn only for a role with the Export/import histories permission; any
other role sees the head of the list without it. It needs a station that accepts writes
("The station is read-only."), because it publishes a run file and an index row, and it is
greyed while another verb of the strip is running ("The previous command is still running.").
What is validated
The file is streamed to a temporary copy (uploads are capped at 1 GB; the feed reads "Importing · file…") and validated there first. A refusal creates no entry:
| Refusal | When |
|---|---|
| The selected file is empty or could not be read. | An empty or unreadable upload. |
| The selected file is not a Ganter Lab run file. | A file that carries no run-file schema history. |
| This file was created by a newer or incompatible version of Ganter Lab and cannot be imported. | A run file from a later or incompatible format. |
| The selected file is not a readable Ganter Lab run file. | Not a SQLite database, or a corrupt one. |
The receipt and the published copy
A file from a supported older baseline is upgraded on the temporary copy only; the
received file is never touched. The copy then has its import receipt, the import
instant and the received file name, stamped into itself, so the record can always state
where the run came from and a rebuilt index restores the Imported mark; a copy re-exported
from another station carried that station's receipt, and this copy's provenance is its
arrival here. The station publishes a fresh local copy under a unique name
(Imported_<run name>_<id>.db) and registers a new, independent entry; the feed reads
"Imported · name · from file (size)" and the list opens on it.
What the copy gets, and never gets
- The imported run gets a brand-new local identity; the original run id stays inside the file as evidence, so two installations can exchange runs without collisions.
- It is never linked to local configuration, even when a procedure of the same name exists: it belongs to no unit, its procedure is none, it cannot be resumed, it never counts toward local productivity, it configures no label for New label, and "(procedure's report)" renders it with the all-sections default.
- Its state is the terminal state frozen in the file: a run ended by an interlock imports as Aborted, and a frozen state that is not terminal is clamped to Completed. A file that never wrote its snapshot (the source station died mid-run) imports as a Failed run named after the file, so it is not lost.
- Nothing is overwritten or merged: importing the same file twice yields two independent entries.
- The responsible travels with the copy as frozen evidence. On a station sharing the same user roster the frozen identity keeps pointing at the same operator; elsewhere it names the person without matching any local user.
Using the imported run
Once imported, the run is browsable, commentable, annotatable and re-exportable like any other, and its label artifacts and report registrations come with it: an artifact's frozen bytes can be reprinted here, while a registration's published PDF is not on this station, so it can be opened or resent only when the source station kept a copy inside the run; otherwise generate a new PDF from the file.
If the app stops mid-import
If the app stops in the narrow window between publishing the file and registering it, the file is not lost: Rebuild run-history index in Settings rescans the run files, which are the source of truth, and gives it its entry back.