Fast_copy new release with new features

New Features

Reflink-based copy on btrfs / XFS / APFS / bcachefs

fast-copy now uses ioctl(FICLONE) on Linux and clonefile(2) on macOS to perform metadata-only CoW clones instead of reading and writing bytes. This makes same-volume copies instant for any file size.

• copy_individual() tries reflink first per file when strategy=reflink is detected
• copy_hybrid() routes ALL files through the reflink path (skips the tar-bundle optimization since each reflink is one instant syscall)
• create_links() uses reflinks before hardlinks for dedup peers — this is architecturally safer than hardlinks because CoW means modifying one peer does not affect the others
• Falls back to byte-stream copy when source and destination are on different filesystems (st_dev check) or when the reflink syscall fails for any reason
• New Phase 6 summary line: ✓ Reflinks: N (CoW shared blocks; modifying one does not affect peers)

Example output on btrfs/XFS-reflink:

Phase 5 — Block copy
  Strategy: reflink (CoW) for 5 files, 12.0 MB
    Metadata-only clone — no data is read or written.

  ██████████████████████████████ 100%  12.0 MB in 0.1s  avg 209.1 MB/s

  Duplicate handling:
    ✓ Reflinks:           4 (CoW shared blocks; modifying one does not affect peers)
    → all reflinked (CoW; safe to modify peers)

Bug Fixes

Windows: tar validator rejected legitimate filenames as "outside destination"

The path validator in _validate_tar_member and the inline check in _ProgressTarExtractor used a case-sensitive startswith comparison to verify extracted paths stay within the destination root. On Windows NTFS (case-insensitive), this incorrectly rejected legitimate files when the user's typed destination path differed in case from the on-disk casing.

Symptom: small files going through the tar block-stream extraction failed with blocked: resolves outside destination even though the filename was harmless (e.g. Halo.4.Forward.Unto.Dawn.2012.1080p.BluRay.x264.AAC5.1-[YTS.MX].srt). Large files were unaffected because they use copy_individual which doesn't go through the tar validator.

Fix: use os.path.normcase() before comparison. No-op on Linux, lowercases on Windows/macOS. All 7 path-traversal security tests continue to block malicious inputs including ../../../etc/passwd, /etc/shadow, etc.

Upgrade Notes

• No breaking changes. Existing command lines work identically.
• No new flags. Reflinks are used automatically when the destination filesystem supports them.
• Reflinks require same filesystem. Copying from ext4 → btrfs uses byte stream for unique files but still uses reflinks for dedup peers at the destination (since both canonical and duplicate live on the same btrfs volume).
• Windows users: the path validator fix resolves false-positive blocked: resolves outside destination errors on case-insensitive NTFS.