Class Crc32
- Namespace
- Archiver.Core.IO
- Assembly
- Archiver.Core.dll
Standalone CRC-32 (ISO 3309 / ZIP polynomial 0xEDB88320) — Archiver.Core takes no NuGet
dependencies, so System.IO.Hashing.Crc32 is not an option, and
Crc32 only exposes the value stored in
the entry's header; .NET does not verify it against the decompressed bytes on read.
Public (not internal) so Archiver.App's FileItem can reuse it for the pending-list CRC-32
column instead of adding a second implementation or a hashing NuGet package there.
public static class Crc32- Inheritance
-
Crc32
- Inherited Members
Methods
Combine(uint, uint, long)
T-F128 follow-up: combines two independently-computed CRC-32 values — crc1
over some data A, crc2 over data B of length len2 — into
the CRC-32 of A followed by B, without re-reading either block. This is what makes hashing one
large file in parallel possible: split the file into chunks, hash each chunk independently
(fresh Crc32.Accumulator per chunk, no shared state, embarrassingly parallel), then
fold the per-chunk results together in order with this method — an O(log len2) operation, not
proportional to the data size.
Standard technique (not invented here) — this is a faithful reimplementation of zlib's public
domain crc32_combine (see zlib's crc32.c), which treats the CRC register as an
element of GF(2)[x]/(the CRC-32 polynomial) and represents "shift the CRC register as if N zero
bytes were appended" as a 32x32 bit matrix, computed via repeated squaring so the whole
operation costs O(log N) bit-matrix multiplications regardless of how large N (len2) is. Both
crc1/crc2 are the normal finished (post-Finish(),
i.e. XOR'd with 0xFFFFFFFF) CRC-32 values — same convention zlib's own public API uses — not
the raw un-finished accumulator register.
public static uint Combine(uint crc1, uint crc2, long len2)Parameters
Returns
Compute(Stream)
Computes the CRC-32 of all remaining bytes in stream.
public static uint Compute(Stream stream)Parameters
streamStream