synology_apm_repo.sdk.presentation.export_target module

The shared <dst>.part staging-file safety contract for a real, on-disk export destination — used identically by the CLI’s export command and the Browser’s own export worker, so the two surfaces can’t silently disagree on when an existing destination is refused or what happens to a partial file once a cancelled export unwinds. Both callers already share presentation.progress’s ProgressMeter for the same underlying ContentSource.export_to() call; this module covers the file-lifecycle half of that same shared concern.

synology_apm_repo.sdk.presentation.export_target.part_path_for(dst)

The staging path an export writes to before renaming to dst on success — <dst>.part, the one naming convention both callers share.

synology_apm_repo.sdk.presentation.export_target.destination_available(dst, *, force)

Whether it’s safe to start writing toward dst — False only when dst already exists and the caller didn’t ask to overwrite it. Checked once, up front, before any real work starts: a truncated-but-plausible-looking output file is a safety-level problem for a restore tool, not just a UX nicety.

A plain synchronous call even from an async caller — one cheap stat(), the same tier as finalize_export()’s replace() and resolve_cancelled_partial()’s unlink(): single filesystem metadata operations, not the bulk data path the SDK offloads with asyncio.to_thread().

synology_apm_repo.sdk.presentation.export_target.finalize_export(part_path, dst)

Renames a successfully-completed part_path to its final dst.

class synology_apm_repo.sdk.presentation.export_target.CancelledPartialOutcome(kept, ever_written)

Bases: object

What happened to part_path once a cancelled export unwound — each caller renders its own message from this, since the CLI and TUI surfaces phrase it differently.

kept: bool

Whether part_path was left on disk (keep_partial=True, or there was nothing to remove because it was never written).

ever_written: bool

False only when export_to() never got past deferring its own first-block-succeeds file creation (e.g. a cloud-sync placeholder cancelled early) — there was never anything to keep or remove either way.

synology_apm_repo.sdk.presentation.export_target.resolve_cancelled_partial(part_path, *, keep_partial)

Decides what happens to part_path once a cancelled export unwinds, and performs it (deletes it unless keep_partial) — the one place this decision is made, rather than the CLI and TUI each hand-rolling their own (previously already diverged: the CLI deleted a cancelled export’s partial file by default, the TUI always kept it).

keep_partial=False always reports (and performs) removal, even when part_path never existed to begin with — “nothing left behind” holds either way, so this branch never needs to check existence at all. Only keep_partial=True needs to distinguish “kept” from “never written,” since claiming a kept file that isn’t there would be actively misleading.