synology_apm_repo.sdk.format.repo_info module¶
repo_info — magic RpiF, 64-byte header + JSON payload
(FORMAT-SPEC.md: repo_info).
Pure bytes -> dataclass decode, zero I/O (the Codec Layer’s charter) — callers
fetch the bytes via an ObjectStore and hand them to parse_repo_info.
DedupRepo.open() always reads and parses this file — a missing
or corrupt repo_info blocks opening the repository at all (FORMAT-SPEC.md:
repo_info) — but none of its parsed values ever drive a chunk-decode decision:
this file’s own storage_algorithm.encrypt_algorithm is not a reliable
encryption signal (see FORMAT-SPEC.md: bucket-header for why, and
BucketFileHeader.is_vault_encrypted’s docstring for the actual one);
every other field here is likewise parsed for display/diagnostics only.
Generation selection for this file on S3/Azure object-storage repositories
(where repo_info may only exist as repo_info.<N>, selected by the
same transaction-log algorithm as db/file_map — FORMAT-SPEC.md:
generation-selection) lives in storage/generations.py; this module only
parses bytes once you already have them.
- class synology_apm_repo.sdk.format.repo_info.RepoInfo(uuid, major, minor, repo_type, repo_flag, is_global_dedup_supported, is_worm_supported, compress_algorithm, encrypt_algorithm, raw)¶
Bases:
objectParsed
repo_info: header UUID plus the (display-only) JSON body fields listed below.rawkeeps the whole decoded payload.
- synology_apm_repo.sdk.format.repo_info.parse_repo_info(data)¶
Parse a
repo_infofile’s full bytes (header + JSON payload).- Raises:
DataCorruptError – A magic or CRC32 mismatch.
FormatError – The payload is truncated relative to the length the header declares.