#[non_exhaustive]pub enum ApplyMode {
Write,
DryRun,
}Expand description
Selects whether ApplyContext mutates the filesystem or runs in
no-op verification mode.
Default is ApplyMode::Write. Override with ApplyContext::with_mode.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Write
Normal apply: open files for write, truncate, unlink, and create directories as each chunk demands. This is the mode every existing caller has been using implicitly.
DryRun
Walk every chunk end-to-end — resolve paths, decompress every DEFLATE
block, validate every chunk-trailer CRC32 — but never open a file for
write and never mutate the filesystem. Filesystem reads still
happen: RemoveAll’s directory walk still enumerates entries (so a
missing or wrong install surfaces as an error), but the fs::remove_file
inside is suppressed. ensure_dir_all / create_dir_all are
suppressed by the same token — a dry-run will therefore NOT fail just
because an expected parent directory is absent, since in Write
mode that absence would have been silently corrected by
create_dir_all. The trade-off favours “tell me whether this patch
will parse and decompress cleanly” over “tell me whether every
directory it would have created already exists”.
CRC validation is exercised for free because chunk trailers are
validated by crate::ZiPatchReader during parsing; a dry-run that
drives the iterator implicitly catches CRC mismatches.
Dry-run does not surface seek/flush failures that a real apply might:
the [NullWriter] sink has no backing buffer to flush, so the
mid-flush errors a real BufWriter over std::fs::File could
raise on seek are absent in this mode.