pub struct Removal {
pub path: String,
pub author: String,
pub requested_unix: u64,
pub moved_to: Option<String>,
pub refused: Option<Refusal>,
}Expand description
A DECLARED removal (delete/rename design §3): a delete asked for from OUTSIDE the pod — a UI, a backend embedding the gateway crate. The caller cannot touch the tree and must never delete the object itself (§9: a cited object deleted from outside wedges every checkout), so it records INTENT here and the syncer performs it at its next barrier: unlink, then cite out, then GC — one manifest generation, and for a rename the same generation that cites the destination.
A FIELD of the cell and not a tombstone InboxEntry, for the reason
boundary_request gives above: consume_inbox HEADs every entry’s
object and is not taught a second shape.
Fields§
§path: String§requested_unix: u64§moved_to: Option<String>For a rename: where the bytes went. Audit trail and conflict message; never load-bearing for correctness.
refused: Option<Refusal>Filled in by the syncer when it REFUSED to perform this removal
— the path had unpublished local edits, was not a file, or
could not be contained. A refused removal is never retried: it
stays here, so the human who asked can read why from any
replica, until a newer removal of the path supersedes it or the
caller withdraws it. Bounded by REFUSED_REMOVALS_CAP.