I move files between a local drive, an external SSD, and a network share often enough that I wanted a small tool to do it safely — not fast, safe. The core rule I set from the start: the tool only copies. It never moves, and it never deletes a source file, no matter how confident it is that the copy succeeded. Trust is earned per-file, not assumed.
The first version was read-only on purpose. Before writing a single byte anywhere, it scanned real folders, fingerprinted files, and just reported what it saw — device status, file counts, rough categories. Only after that worked did it start copying, and every copy was followed by an independent read-back and checksum comparison of both the source and the destination. A copy that can't prove itself byte-for-byte doesn't count as done.
What "safe" actually had to survive
The real test was interruption. Large transfers over a network share are slow enough that something will eventually cut them off — a process restart, a dropped connection, a reboot. So I built a resumable protocol: every 64 MiB, the tool writes a chunk, flushes it to disk, reads it back, checks its hash, and only then commits a checkpoint to a local database. If anything before that checkpoint is trusted, everything after it is not.
Then I tested it properly. A 10 GiB transfer to network storage was deliberately killed 40% of the way through. I restarted the whole dashboard process — not just resumed a paused job, but brought the tool back up from nothing — and asked it to continue. It found the last verified checkpoint, confirmed the source file hadn't changed size, modification time, or identity since the interruption, and resumed writing from exactly that byte offset. It finished the remaining 60%, ran a full checksum over the entire file, and the result matched the source exactly.
Resume only works if the source is provably the same file it started with. If the size, timestamp, or device identity don't match, the tool refuses to resume and forces a fresh verification instead of trusting a checkpoint that might belong to a different file. That refusal is the point — a resumable copy that resumes onto the wrong data is worse than one that just fails.
What it still won't do
No move, no delete, no overwrite of an existing destination file. Those are staying out for now, not because they're hard, but because a transfer tool that can silently destroy data is a different kind of tool than one that can only silently waste your time. Once move and resume-after-crash recovery both hold up under the same kind of deliberate abuse, that boundary can move — carefully, and one capability at a time.