Backup history is not proof
An earlier successful upload is insufficient evidence for deleting the phone copy. The current phone item, receiver identity, device identity, destination generation, manifest entry, stored file, size, and verification state must still agree. Contradictory or inaccessible state blocks the destructive path.
Transfer and verification
The Android side uses Kotlin, Compose, MediaStore, Room, and a foreground transfer service. The Windows receiver uses ASP.NET Core, per-device authentication, pairing/rediscovery, explicit destination ownership, capacity accounting, and a manifest of verified files.
State is explicit
FAILED can be entered from transfer or verification stages. A failure never promotes an item to deletion eligibility.
Fail-closed cases
| Observed or possible condition | HomeDrive behavior |
|---|---|
| Expected Windows copy missing | Deletion blocked; item returns to pending/current-state handling |
| Wrong size or byte hash during transfer | Transfer fails; final verified state is not written |
| Receiver, device, or destination generation changed | Historical verification is rejected for the active target |
| Phone metadata changed since verification | Deletion blocked until the new item state is reconciled/backed up |
| Destination capacity falls below reserve | Oversized run is rejected or transfer stops before crossing the reserve |
| Write is interrupted | Incomplete temporary data is removed; already verified backups remain untouched |
| Receiver state is missing, inaccessible, or contradictory | Destructive action fails closed |
Finalized backup media is also outside the receiver's ordinary deletion gateway. Cleanup is restricted to HomeDrive-owned temporary/staged files and write probes.
Current truth vs historical truth
The primary Backup status path rescans MediaStore identity/metadata and checks expected Windows copies in authenticated batches. Full byte verification remains available separately when a fresh archive-integrity audit is required. Free Up performs its own fresh verification rather than trusting a previous status screen.
Settings are captured when a run is admitted. Changing folders or media types while a backup is running affects the next run, not the already admitted one.
Representative physical validation
A hardware validation used generated test media on the real Android/Windows path. The current catalog was expanded to about 3,031 items, with roughly 7,650 historical/current ledger rows, while real media remained excluded from the test runs.
During one admitted run, settings were changed while transfer continued. The active denominator and admitted files remained fixed; the changed settings applied to the following run. A three-file, 161 MB run completed all three files with zero failures, and the subsequent changed-scope run admitted exactly the two expected files.
The final independent audit recomputed local source hashes and checked retained Windows copies against manifest size/hash data: 281 generated copies, 221,003,803 bytes, zero mismatches. Saved selection/settings state was restored with zero differences. These are representative test results for that hardware/session, not a general performance benchmark.