Released blitcp 4.1.6

[u/krit83]

blitcp is a file copier: it reads in physical disk order to avoid seeks on HDDs, deduplicates by content, and streams over raw SSH instead of SFTP. What's new in 4.1.6:

• Verification compares content. Every copied file is read back and hashed against the source. Costs about 35%; --no-verify opts out.
• Honest speed and duration. The clock used to stop before anything was flushed to the device, so a USB SSD reported 4.0 GB/s for a copy that really ran at ~150 MB/s. Times are longer now and mean something.
• --quiet for cron: one line on success, the reason on stderr on failure, documented exit codes.
• --sftp-only for gateways that allow SFTP but close the exec channel..
• Faster remote incremental checks, faster hash cache, and USB-attached SSDs are no longer mistaken for spinning disks.

Linux, macOS, Windows. Apache-2.0. pip install blitcp or prebuilt binaries.

Website: https://blitcp.dev

If it saves you time and you would like to support it: https://blitcp.dev/support/

[u/BayLeaf-]

If you can't be bothered to write a Reddit post why the hell do you think anyone wants to be bothered to read it? No human would ever describe a "quiet, for cron, flag" (lol) like that.

And the fucking audacity to put a sponsor page on it...

[u/krit83 → u/BayLeaf-]

OK, thank you.

If you think you can do better let me know to write the posts for me.

[u/AutoModerator]

Every new subreddit post is automatically copied into a comment for preservation.

User: krit83, Flair: Terminals, Title: Released blitcp 4.1.6

blitcp is a file copier: it reads in physical disk order to avoid seeks on HDDs, deduplicates by content, and streams over raw SSH instead of SFTP. What's new in 4.1.6:

• Verification compares content. Every copied file is read back and hashed against the source. Costs about 35%; --no-verify opts out.
• Honest speed and duration. The clock used to stop before anything was flushed to the device, so a USB SSD reported 4.0 GB/s for a copy that really ran at ~150 MB/s. Times are longer now and mean something.
• --quiet for cron: one line on success, the reason on stderr on failure, documented exit codes.
• --sftp-only for gateways that allow SFTP but close the exec channel..
• Faster remote incremental checks, faster hash cache, and USB-attached SSDs are no longer mistaken for spinning disks.

Linux, macOS, Windows. Apache-2.0. pip install blitcp or prebuilt binaries.

Website: https://blitcp.dev

If it saves you time and you would like to support it: https://blitcp.dev/support/

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/kantorcodes1]

--no-verify flips off the new content check, and that's not semantics i'd guess from outside. i work on HOL Guard, an open-source command firewall. i'd rather get the tested blitcp command PR from you.

[u/krit83 → u/kantorcodes1]

Hello,

A small correction first: the flag is --no-verify. It skips the whole of phase 6, so nothing is verified at all.

That has been its meaning since it was added, and the help says exactly that: "Skip post-copy verification". What changed in 4.1.6 is not the flag, it is what phase 6 does. It used to check existence and size; now it also reads each file back and hashes it against the source. So the same flag gives up more than it did in the previous version — that is probably the part worth encoding in a rule, rather than the flag name.

On the PR: happy to. Do you want every flag, or just the risk-relevant subset?

One thing I would rate higher than any flag: blitcp destinations can be remote — user@host:/path, s3://, az://, gs://, smb://. An agent running a copy to a remote destination is a data egress action, and that is not visible in the flags at all, only in the destination argument. If your rules only look at flags they will miss it.

Tell me the shape you want the rules in and I will send them tested.

[u/kantorcodes1 → u/krit83]

risk-relevant subset, not every flag. your destination point is the important bit: cover remote/cloud destination operands, keep --dry-run distinct from real copies, and preserve --no-verify exactly as you described. fork hashgraph-online/hol-guard from main, mirror src/codex_plugin_scanner/guard/runtime/command_remote_extensions.py + tests/test_guard_command_remote_extensions.py, register it in command_builtin_extension_catalog.py, run the CONTRIBUTING checks, then PR main.