cwdio
Menu
Download

Feature · Move & protect

Transfers you can trust: verified copies, a queue that survives

Every copy and move runs through one queue: optional CRC verification, resume at the byte offset after a disconnect, a journal that survives a restart, retry.

Default shortcut: F5 · F6 · Ctrl+L Updated 16 August 2026 View as Markdown

cwdio's Operations drawer open beside the two file panels while a copy runs. Its header reads 1 running and 2 done; the top row is a node_modules folder being copied, with a live progress bar, a transfer rate and a time remaining; the two rows under it are finished copies of public and docs, each with a filled green bar and a Verified tick.
A transfer is a row in a drawer, not a modal dialog you have to sit and watch — both panels stay live behind it. Finished copies keep their verified tick as history, and closing the app does not lose what is still queued.

F5 copies the selection to the other panel and F6 moves it — the same keys the orthodox file managers have used for thirty years. What is different is what happens next: the operation joins a queue that verifies if you ask, resumes if a drive vanishes, survives closing the app, and tells you which file failed instead of leaving you to guess.

What it does

  • One queue for every transfer. Copies, moves, deletes, packs, sync plans and the AI assistant’s actions all go through it, so every one of them can be cancelled, watched, retried and undone the same way. Ctrl+L (or the status-bar heartbeat) opens the Operations drawer: active operations on top, each with a progress bar, bytes / total · speed · ETA, per-item cancel and dismiss.
  • Verified copies. Optional (Preferences ▸ Transfers, or the Tools menu). A CRC-32 is computed on the source bytes during the stream and checked against the written file before it is renamed into place.
  • Resume after a disconnect. An unreachable device turns the operation amber and paused, not failed; a watcher polls the endpoints every few seconds and re-queues the operation, continuing partial files at their byte offset and skipping files that already arrived.
  • A journal that survives a restart. Every live copy and move is mirrored to an atomically written journal. On the next start unfinished entries are re-admitted as paused operations and resume — a crash mid-copy continues its partial file where it stopped. Orphaned temporary files of an operation that can no longer be restored are swept, never leaked.
  • Per-file skip and retry. One locked child does not abort a tree. Failures are listed per file with the reason, a What’s locking this file? query against the Windows Restart Manager, and a per-file retry.
  • Conflict handling before the queue. Targets that already exist are found in one batched check and you choose overwrite, skip or keep both (name (2).ext) up front — the queue then runs without stopping to ask.
  • Progress where you can see it. The Windows taskbar button shows the overall progress, and turns amber while an operation is paused. Closing the window with a transfer running asks first; a paused operation is safe to leave, because it is journaled.
  • A history you can export. Completed rows stay in the drawer with a Reveal where it landed button that navigates to the destination and selects the file; Export log… saves the whole history as text.
  • Instant for the small things. New folder, new file and rename are direct, validated operations that refuse to clobber; a nested name such as src/components/widgets creates the whole chain in one gesture.

How to use it

  1. Select files in one panel, put the destination in the other, press F5 (copy) or F6 (move). File ▸ Copy to folder… takes a typed destination instead.
  2. Turn on Verify copies for anything you cannot afford to have silently corrupted — a backup to a USB drive, a transfer over Wi-Fi.
  3. Watch the drawer with Ctrl+L, or just carry on: the taskbar shows the progress. If a drive drops, plug it back in; if you have to leave, close the app.
  4. If a row turns amber with a failure count, expand it, see which file and why, and retry when the file is free.

Under the hood

Bytes never cross the renderer process. The copy engine runs in a separate host process and only control and progress messages travel between it and the interface, which is why a 10 GB move does not stall the window (ADR 0015 — the engineering notes tell the story). Copies stream with a 4 MiB buffer and up to eight files in flight; files up to 64 MiB use the kernel’s own copy call, which is faster and gets SMB copy-offload and ReFS block cloning that no stream can. Every generic copy writes to a sibling temporary file and publishes it with one rename only after the stream — and, when verifying, the CRC — completes, so a failure mid-stream never leaves a partial or empty target.

What it deliberately does not do

  • It does not verify by default: verification costs a second read of every byte, so it is a preference you switch on for the transfers that deserve it.
  • A resumed verified copy restarts the file rather than continuing at the offset — the CRC needs the whole stream.
  • Cancel is between files for small files (the kernel copy is opaque) and mid-file for anything that streams.

Questions

What does “verified copy” actually check?

With Verify copies on, cwdio accumulates a CRC-32 of the source bytes while streaming them, reads the freshly written file back, and compares. A mismatch fails the operation with an integrity error before the file is published to its final name — nothing half-written is ever left in place. Completed rows show a ✓ Verified chip in the Operations drawer. It is off by default because it costs a second read of every file.

What happens if the drive disconnects halfway?

The operation pauses instead of failing. cwdio keeps the partial temporary file, watches for the endpoint to come back, and when it does the copy continues from the byte offset it reached — files already copied are recognised by size and date and skipped. Closing the app is just a longer disconnect: unfinished operations are journaled and resume on the next start.

One locked file failed. Did the whole copy stop?

No. Inside a tree copy a locked or unreadable file is recorded and its siblings carry on; only a cancel, an integrity mismatch or an unreachable device stops the whole operation. The Operations drawer shows an amber “N failed” chip that expands to one row per file, with What's locking this file? and Retry for each — or Retry failed files for all of them. A move keeps the entire source intact when any file failed.

How fast is it?

Files up to 64 MB use the kernel's own copy (CopyFileW on Windows), which is measured about 1.7× faster than a JavaScript stream and gets SMB copy-offload and ReFS block cloning for free; larger, verified and resumed files stream with a 4 MB buffer and up to 8 files in flight. Small-file trees copy at roughly 1 800 files a second on NTFS. The benchmarks page has the numbers.