Skip to main content

Preservation & Trust Model

FileCabinet's primary goal is long-term reliability. To ensure that digital records remain intact, readable, and verifiable, the application implements a strict preservation model based on a formal vault lifecycle, trust classification, and cryptographic determinism.

The Vault Lifecycle​

An artifact inside FileCabinet transitions through defined lifecycle states. Each state corresponds to physical file placement on disk and specific database fields:

graph TD
    A[External File] -->|Ingest: Copy| B[Retained Copy]
    A -->|Ingest: Move| C[Retained Owner]
    B & C -->|Operational State| D[Active Vault Item]
    D -->|Star/Pin| E[Priority Archive]
    D -->|Suspect/Risk| F[Quarantine Folder]
    D -->|Restore Action| G[External Restore Destination]
    D -->|Delete Action| H[Deleted Forever]
    F -->|Validation Clear| D
    F -->|Validation Fail| H

1. Ingest Modes (Move vs. Copy)​

  • Move into Vault: The vault takes ownership of the file. The original file is deleted after the copy is written, verified, and cataloged. Useful for cold storage archives and cleanup.
  • Copy into Vault: The vault copies the file but leaves the original untouched. Useful for keeping active working copies while maintaining a baseline in the vault.

2. Operational States​

  • Active Vault Item: Placed inside the vault's relative path (items\yyyy\MM\) and tracked in the catalog.
  • Quarantine: Files moved here are physically moved out of the active items directory to the quarantine/ folder. This strips their active path relations and indexes, keeping the system safe while you review suspicious artifacts.
  • Delete Forever: An explicit, irreversible action. The file is shredded from the filesystem and its catalog record is expunged.

:::danger Caution Delete Forever is permanent. If you want to safely remove an item from your daily views without deleting the underlying file, use the Quarantine mode first. :::

Trust and Verification Model​

Rather than assuming all files are equal, FileCabinet asks the operator to define structured metadata reflecting the quality and origin of each asset:

Metadata FieldChoices / PurposeImpact on Verification
Trust ClassificationVerified, Unverified, Questionable, UntrustedFlags files that require explicit validation runs.
Acquisition MethodDownload, Direct Transfer, Recovered, Manual IngestTracks source provenance for forensic review.
Retention PriorityLow, Medium, High, PermanentInfluences backup scopes and duplicate cleanup rules.
Hash VerificationVerified, Stale, Mismatched, PendingThe actual cryptographic state of the physical file.

Why Determinism Matters​

In standard filesystems, files can experience bit rot—microscopic data corruption caused by disk degradation, driver bugs, or unexpected power losses—without the OS throwing any warnings.

FileCabinet avoids this by treating files as deterministic mathematical values.

When a file is ingested, the system generates its cryptographic signature. During validation checks, the app recomputes this signature:

  • If the signature matches, the file is healthy.
  • If it differs by even a single bit, the catalog flags a Hash Mismatch.

Hash Choices and Compatibility​

FileCabinet allows you to select which hashes to calculate in Settings. New catalogs calculate SHA-256 by default, but others can be toggled:

:::tip Modern Strong Hashes

  • SHA-256: The industry standard. Highly compatible with third-party manifests.
  • BLAKE3: Extremely fast, tree-structured cryptographic hash. Excellent for processing gigabyte-scale disk images and installers rapidly.
  • KangarooTwelve & SHA3-256: Keccak-based hashes representing modern, future-proof standards. :::

:::warning Legacy & Compatibility Checksums

  • MD5 & SHA-1: Supported only to match existing vendor catalogs, retro-gaming databases, or old archives.
  • CRC32: Fast, non-cryptographic checksum used for ZIP and hardware verification. :::