releases

BitSpeed Transfer Adds a Clean Command That Gives Back Disk Space After Delivery

Transfer keeps everything by default. That’s deliberate. Stored chunks are what let a receiver prove its progress after a crash. Once a file is delivered, though, they’re just a second copy taking up room. In the Transfer case study, the receiver held 513 MB after delivering a 256 MiB file.

Transfer 0.2.0 adds bitspeed-transfer clean. Stop the receiver and point it at the root:

./bitspeed-transfer clean --root=receiver --dry-run
./bitspeed-transfer clean --root=receiver

Before clean the receiver holds the delivered file and its stored chunks. After clean only the delivered file and its proof remain.

We ran the released 0.2.0 binary on that same case-study receiver. The dry run reported 256 chunks and 268,435,456 bytes it would remove. The real run removed them, and the root went from 513 MB to 257 MB. Then we started the receiver again and repeated the original send command. It came back with transferred true and the same receipt, digest 651b3dcd…b883683, without sending a byte.

What it keeps

Clean is narrow on purpose. It takes the receiver’s lock, so it won’t run while serve is using the root. Before touching anything it runs the same recovery the receiver runs at startup. That re-reads every completed file and checks it against its manifest. If a delivered file has been damaged since, that session is marked failed and its chunks stay for investigation.

Then it removes the stored chunk files of completed sessions, and nothing else. The delivered file, the receipt, the witness link, the journal, any corrupt-chunk evidence and every unfinished transfer are left alone. A crash halfway through is harmless: a completed transfer never needed its chunks, and running clean again finishes the job. It also works on a full disk, which is usually when you need it.

What it doesn’t do

It doesn’t delete whole sessions or delivered files. That’s still the manual offline retention procedure. It doesn’t run automatically, and it doesn’t change how much the receiver reserves for each transfer. The sender’s snapshot is untouched too. Once chunks are gone, a delivered file that gets damaged later can’t be rebuilt from them, so keep a verified copy of anything you can’t send again.

Nothing else changed. The protocol and storage layout are the same as 0.1.0, so 0.1.0 and 0.2.0 senders and receivers work together. Delivery is still Linux and macOS only. Before release, an independent review found no blockers. Its smaller findings were fixed, and tests were added for damaged files, a full disk, a failed directory sync and cancellation.

Get it from the download page. The Transfer guide has the full command reference.