Accidently made and useless for me. Good luck.
  • C++ 98.3%
  • Makefile 1.7%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-08-31 11:58:10 -04:00
src first commit 2026-08-31 11:58:10 -04:00
.gitignore first commit 2026-08-31 11:58:10 -04:00
Makefile first commit 2026-08-31 11:58:10 -04:00
README.md first commit 2026-08-31 11:58:10 -04:00

Dev Drive Turbo Cloner

ReFS Block Cloning + ODX Offload + Turbo Copy — one GUI. Now cross-platform: Windows + Linux.

Status: Untested preview — Windows ReFS/NTFS path builds and runs (DevDClone.exe verified). Linux btrfs/XFS FICLONERANGE + copy_file_range path compiles via Makefile but has not been run on a real Linux btrfs volume. ext4 fallback and USB Turbo not yet benchmarked. Expect EXDEV/ENOSYS → Turbo fallback until tested. Contributions/test reports welcome.

The original "instant clone" idea only works same-volume on a CoW filesystem. Windows: ReFS Dev Drive via FSCTL_DUPLICATE_EXTENTS_TO_FILE. Linux: btrfs/XFS via FICLONERANGE (cp --reflink). This version adds the cross-drive path so big ISOs to a bootable USB go at hardware max on both OSes.

What it does

Scenario Windows method Linux method Speed
Same Dev volume repo → repo-copy FSCTL_DUPLICATE_EXTENTS_TO_FILE (ReFS) FICLONERANGE / FICLONE (btrfs/XFS reflink=1) ~50ms for 10GB, 0 extra disk (CoW)
Same volume but non-CoW FS (NTFS client / ext4) FSCTL_DUPLICATE_EXTENTS_TO_FILE_EX (Server 2022+ only) otherwise fail copy_file_range (kernel zero-copy) fast but not instant
Cross-drive, offload-capable HW (NVMe/UASP SAN) FSCTL_OFFLOAD_READ/WRITE (ODX token) copy_file_range / NFS 4.2 server-side copy no RAM bounce, storage does it
Cross-drive to bootable USB (FAT32/exFAT/NTFS/ext4 stick) Turbo FILE_FLAG_NO_BUFFERING + 4MB + SetFileValidData Turbo O_DIRECT 4MB + sendfile ~2-3× Explorer/cp, saturates USB bus

Modify a cloned file → ReFS/btrfs/XFS writes only changed blocks (Copy-on-Write).

Build

Requires g++ -std=c++20 and w64devkit on Windows or build-essential on Linux.

Windows (ReFS Block Clone + ODX + Turbo):

mingw32-make        # or: g++ -std=c++20 -O2 src/clone_engine.cpp src/main.cpp -o DevDClone.exe -municode -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lshell32 -lole32 -lcomctl32 -ldwmapi -luxtheme
.\DevDClone.exe     # dark Win32 GUI, auto-picks Block Clone → ODX → Turbo

Linux (reflink + copy_file_range + Turbo):

make                # CLI, no extra deps: builds ./DevDClone
# optional GTK GUI (if you want a window like Windows):
sudo apt install libgtk-3-dev
make HAVE_GTK=1     # builds with GTK file choosers

./DevDClone --help
./DevDClone --src ~/projects/monorepo --dst /mnt/fast/monorepo-copy
./DevDClone --src ./ubuntu-24.04.iso --dst /media/usb/ --file
# interactive mode (no args) prompts for source/dest
./DevDClone

Linux needs a reflink-capable FS for instant: mkfs.btrfs /dev/sdX -f or mkfs.xfs -m reflink=1 /dev/sdX. ext4 is like NTFS client — no reflink (see below).

Use

Windows GUI:

  1. Clone Project — pick React monorepo / node_modules / venv folder → pick dest (same Dev Drive = instant). Handles 50k files recursively, auto-creates dirs, reports per-file method.
  2. Clone / Copy ISO — pick ubuntu.iso → pick USB drive E:\. Auto-detects same-volume vs cross-drive and picks Block Clone → ODX → Turbo.

Status bar shows ReFS Block Clone — INSTANT vs Turbo Copy — 4MB NO_BUFFERING so you know which path fired.

Linux CLI (same flow):

./DevDClone --src ~/repo --dst /mnt/btrfs_fast/repo-copy
# logs: Src: ... [btrfs] Dst: ... [btrfs] Same volume: YES reflink-capable: YES → FICLONERANGE — INSTANT
./DevDClone --src ./big.iso --dst /media/usb/ --file
# logs: [ext4 → vfat] Cross-volume — reflink impossible. Using copy_file_range → Turbo.

Single-file equivalent without the app: cp --reflink=always big.iso clone.iso (fails with Operation not supported if not btrfs/XFS).

For bootable USBs

Bootable USBs must stay FAT32 (UEFI). ReFS/btrfs can't boot. Use Turbo path + keep master ISO library on Dev Drive / btrfs volume with instant clones; write only the ISO you need. Or use Ventoy (Windows + Linux, format once, drag ISOs).

Where will I see ReFS? (Windows)

You won't by default — C: and any store-bought USB are NTFS/exFAT/FAT32. ReFS only appears where you or an admin explicitly created it:

1. Dev Drive on your PC (the only Win11 client use) Settings → Storage → Advanced storage settings → Disks & volumes → Create Dev Drive (≥50 GB, needs unpartitioned space or a VHD). Shows as D: ReFS — app log then reads [ReFS] and badge ● ReFS Block Clone — INSTANT. Intended for repo/, node_modules/, venv/, .git/, build/ caches and your D:\ISOs\ library. Also runs AV in performance mode for that letter.

Verify: fsutil fsinfo volumeInfo D: or Get-Volume | Format-Table DriveLetter,FileSystem → ReFS.

2. Server / datacenter

  • Storage Spaces / Storage Spaces Direct / Azure Stack HCI — ReFS is the default for pools, auto-heals CRC64 integrity streams via mirror + weekly scrub.
  • Backup repos — Veeam/DPM on Windows Server formatted ReFS 64K for Fast Clone synthetic fulls (same FSCTL_DUPLICATE_EXTENTS_TO_FILE API, merges 1 TB in seconds).
  • Hyper-V hosts storing .vhdx on ReFS — checkpoint merges use block cloning.

You will NOT see it on: C: boot (must be NTFS), bootable USB (FAT32 for UEFI), most external HDDs, WSL2 (ext4), NAS (ext4/btrfs).

If both paths log [NTFS] (e.g. C:\Downloads → C:\tesss) you're on NTFS — engine correctly falls back to ODX → Turbo at bus max. Create/move the project to the D: Dev Drive to see the instant path.

Same story — ext4 (Ubuntu default) is your NTFS: no reflink, instant fails.

1. btrfs volume (your Dev Drive)

sudo mkfs.btrfs -L fast /dev/nvme0n1p3
sudo mount /dev/nvme0n1p3 /mnt/fast
# or enable on existing XFS:
sudo mkfs.xfs -m reflink=1 -L fast /dev/nvme0n1p3

App log then reads [btrfs] / [XFS] and reflink-capable: YES → FICLONERANGE — INSTANT. Intended for the same ~/repos, node_modules, venv, /var/tmp/build on that mount.

Verify: stat -f /mnt/fast (Type: btrfs), findmnt -o TARGET,FSTYPE, or ./DevDClone logs it. Confirm reflink works: cp --reflink=always /mnt/fast/a /mnt/fast/b && btrfs filesystem du /mnt/fast/b shows shared extents.

2. Server / datacenter

  • btrfs / XFS reflink / ZFS / bcachefs on Ceph, NAS, Proxmox/TrueNAS — VM images, containers, snapshots all use FICLONERANGE/copy_file_range server-side (like Veeam on ReFS).
  • NFS 4.2 / SMB server-side copy — the Linux ODX (copy_file_range across hosts).

You will NOT see it on: ext4 root (/), FAT32/NTFS USB, most default desktop installs, tmpfs. If both paths log [ext4] you're on ext4 — engine falls back to copy_file_range → Turbo (fast kernel copy, not instant). Create/move the project to a btrfs/XFS mount to see instant.

NTFS vs ReFS (Windows) / ext4 vs btrfs/XFS (Linux)

NTFS / ext4 ReFS / btrfs / XFS(reflink=1) / ZFS
Design Journaled MFT / journaled ext4, in-place updates Copy-on-Write, checksums per block (ReFS CRC64 / btrfs crc32c), integrity streams/scrub
Healing chkdsk / fsck, no per-block checksum Auto-heal from Storage Spaces mirror / btrfs raid1 scrub
Fast clone Only FSCTL_DUPLICATE_EXTENTS_TO_FILE_EX on Server 2022+ NTFS, otherwise fail / ext4 never Native FSCTL_DUPLICATE_EXTENTS_TO_FILE / FICLONERANGE+FICLONE — instant metadata clone, 0 extra disk, CoW
Limits 8 PB vol / 256 TB file, supports EFS/compression/quotas, bootable / ext4 bootable 35 PB vol / 256 TB file, no EFS/quotas on ReFS, not bootable on Win11 client / btrfs not default boot on Ubuntu
Use for C:, USB, general files / / root Dev Drive (node_modules/venv/git/VHDX) / /mnt/fast (node_modules/venv/containers/VM images), HCI/VM hosts, backup repos

Engine (src/clone_engine.h:1 + src/main.cpp:1)

Windows: ReFS FSCTL_DUPLICATE_EXTENTS_TO_FILE → FSCTL_OFFLOAD_READ/WRITE → Turbo FILE_FLAG_NO_BUFFERING + SetFileValidData Linux: FICLONERANGE/FICLONE → copy_file_range → Turbo sendfile/O_DIRECT

Dispatcher:

  • smart_copy_file() — BlockClone → ODX → Turbo
  • clone_directory() — recursive tree clone (handles 50k files), progress callback, per-file fallback
  • turbo_copy() — 4MB aligned buffers, zero-fill skip (Windows SetFileValidData / Linux sendfile)
  • Falls back to std::filesystem::copy_file if all ioctls fail
  • Same CloneMethod enum, is_same_volume() (GetVolumePathName vs stat.st_dev), get_volume_fs() (GetVolumeInformation vs statfs), method_name().